Virtual pos terminal method and apparatus

ABSTRACT

Methods, systems, and storage media are described for processing point of sale (POS) transactions. In embodiments, a computing device may receive a transaction initiation, and provide a selection of a payment credential to be used to process a POS transaction. The computing device includes a trusted execution environment to process the POS transaction in response to the selection of the payment credential. The trusted execution environment may comprise a payment credential storage unit to store payment credentials and a virtual POS terminal that may validate a merchant terminal associated with the transaction initiation, process the POS transaction using the selected payment credential to generate payment data, and encrypt the payment data. The computing device may communicate the encrypted payment data to a cloud POS service for further processing. Other embodiments may be described and/or claimed.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a Continuation of U.S. application Ser. No.14/739,911, filed on Jun. 15, 2015 entitled “VIRTUAL POS TERMINAL METHODAND APPARATUS”, the contents of which is hereby incorporated byreference in its entirety.

FIELD

The present disclosure relates to the technical field of electronictransactions, and in particular, to apparatuses, methods and storagemedia for providing a virtual point of sale (POS) terminal.

BACKGROUND

In today's world of commerce there are two dominant methods of makingpurchases. One is categorized as “card-present”, where the card holderand payment card are physically present at the time of transaction, andthe other is “card-not-present”, where the card holder is not physicallypresent during the transaction. The former transactions typically occurat a physical establishment (e.g., store, restaurant, gas station,etc.), while the latter typically occur during making purchases over theInternet (also referred to as “ecommerce” purchases) or making purchasesvia phone or mail-order. Card-present transactions typically enjoy farless fraud than card-not-present transactions. This is often attributedto the ability to prove credential authenticity (i.e., authenticity ofthe payment card being used) and card holder legitimacy (i.e., theindividual making the transaction is the card holder or an authorizedagent of the card holder). The enforcement of these two attributes istypically the responsibility of a physical point of sale (POS) terminaland/or other like computing device that can verify correctness of theinformation contained on the card and identity authentication, which isgenerally a personal identification number (PIN), a card holdersignature, and the like.

Most ecommerce transactions require a user to input payment cardinformation and cardholder identification information into text fieldsof a web-based user interface. Additionally, most phone-order purchaserequire customers to recite payment card information and cardholderidentification information over the phone. This is because in mostcard-not-present transactions, the terminal-based authentication methodsare usually not available. Furthermore, most current fraud preventionmeasures for card-not-present transactions, such as typing/reciting theaccount number contained on the front of a payment card plus otheridentifying information like a 3-digit cardholder verification value(CVV) on the back of most payment cards, have been demonstrated to notreduce fraud to the level experienced by card-present transactions.Moreover, the attempts to strengthen cardholder presence assurances forcard-not-present transactions has resulted in the introduction of onlineauthentication protocols, such as the XML-based 3D Secure (which is alsoknown by various trade names including Visa® Verified by Visa,MasterCard® SecureCode, American Express® SafeKey, and JCPInternational® J/Secure). These protocols introduce an additionalauthentication step in the payment checkout process that verifiescardholder identity through the card-issuing bank. However, theadditional verification steps introduced by the aforementioned protocolstend to result in customer frustration in the form of online shoppingcart abandonment, which may lead to a loss of revenue for ecommercemerchants.

Accordingly, it may be desirable to bring the user experience andtransaction security aspects of a physical POS terminal (i.e.,card-present transactions) to online, phone-order, and/or mail-ordertransactions (i.e., card-not-present transactions). Furthermore, it maybe desirable to provide transaction security for card-not-presenttransactions while reducing a number of steps for providing payment cardverification and cardholder authorization.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will be readily understood by the following detaileddescription in conjunction with the accompanying drawings. To facilitatethis description, like reference numerals designate like structuralelements. Embodiments are illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings.

FIG. 1 illustrates an arrangement for conducting electronic transactionwith virtual POS terminal of the present disclosure, in accordance withvarious example embodiments;

FIG. 2 illustrates the components of an example computing device havingthe virtual POS terminal, in accordance with various exampleembodiments;

FIG. 3 illustrates the components of another example computing devicewith the virtual POS terminal, in accordance with various other exampleembodiments;

FIG. 4 illustrates an arrangement for conducting electronic transactionwith virtual POS terminal of the present disclosure, in accordance withvarious other example embodiments;

FIG. 5 illustrates the components of another example computing deviceand a cloud trusted execution environment with the virtual POS terminal,in accordance with various other example embodiments;

FIG. 6 illustrates a method of processing a POS transaction using thevirtual POS terminal, in accordance with various example embodiments;

FIGS. 7-14 illustrate stages of performing the method of FIG. 4;

FIG. 15 illustrates an example process for processing a POS transactionusing the virtual POS terminal, in accordance with various embodiments;and

FIG. 16 illustrates a flow diagram illustrating a POS transaction usingthe virtual POS terminal, in accordance with various embodiments.

DETAILED DESCRIPTION

In the following detailed description, reference is made to theaccompanying drawings which form a part hereof wherein like numeralsdesignate like parts throughout, and in which is shown by way ofillustrated embodiments that may be practiced. It is to be understoodthat other embodiments may be utilized and structural and/or logicalchanges may be made without departing from the scope of the presentdisclosure. Therefore, the following detailed description is not to betaken in a limiting sense, and the scope of embodiments is defined bythe appended claims and their equivalents.

Various operations may be described as multiple discrete actions and/oroperations in turn, in a manner that is most helpful in understandingthe claimed subject matter. However, the order of description should notbe construed to imply that the various operations are necessarily orderdependent. In particular, these operations may not be performed in theorder of presentation. Operations described may be performed in adifferent order than the described embodiments. Various additionaloperations may be performed and/or described operations may be omittedin additional embodiments.

For the purposes of the present disclosure, the phrase “A and/or B”means (A), (B), or (A and B). For the purposes of the presentdisclosure, the phrase “A, B, and/or C” means (A), (B), (C), (A and B),(A and C), (B and C), or (A, B and C). For the purposes of the presentdisclosure, the phrase “at least one of A and B” means (A), (B), or (Aand B).

The description may use the phrases “in an embodiment”, or “inembodiments”, which may each refer to one or more of the same ordifferent embodiments. Furthermore, the terms “comprising,” “including,”“having,” and the like, as used with respect to embodiments of thepresent disclosure, are synonymous. The terms “coupled,”“communicatively coupled,” along with derivatives thereof are usedherein. The term “coupled” may mean two or more elements are in directphysical or electrical contact with one another, may mean that two ormore elements indirectly contact each other but still cooperate orinteract with each other, and/or may mean that one or more otherelements are coupled or connected between the elements that are said tobe coupled with each other. The term “directly coupled” may mean thattwo or more elements are in direct contact with one another. The term“communicatively coupled” may mean that two or more elements may be incontact with one another by a means of communication including through awire or other interconnect connection, through a wireless communicationchannel or ink, and/or the like.

As used herein, the term “logic” and “module” may refer to, be part of,or include an Application Specific Integrated Circuit (ASIC), anelectronic circuit, a processor (shared, dedicated, or group) and/ormemory (shared, dedicated, or group) that execute one or more softwareor firmware programs, a combinational logic circuit, and/or othersuitable components that provide the described functionality.

Also, it is noted that example embodiments may be described as a processdepicted as a flowchart, a flow diagram, a data flow diagram, astructure diagram, or a block diagram. Although a flowchart may describethe operations as a sequential process, many of the operations may beperformed in parallel, concurrently, or simultaneously. In addition, theorder of the operations may be re-arranged. A process may be terminatedwhen its operations are completed, but may also have additional stepsnot included in the figure(s). A process may correspond to a method, afunction, a procedure, a subroutine, a subprogram, and the like. When aprocess corresponds to a function, its termination may correspond to areturn of the function to the calling function and/or the main function.

As disclosed herein, the term “memory” may represent one or morehardware devices for storing data, including random access memory (RAM),magnetic RAM, core memory, read only memory (ROM), magnetic disk storagemediums, optical storage mediums, flash memory devices and/or othermachine readable mediums for storing data. The term “computer-readablemedium” may include, but is not limited to, memory, portable or fixedstorage devices, optical storage devices, wireless channels, and variousother mediums capable of storing, containing or carrying instruction(s)and/or data.

Furthermore, example embodiments may be implemented by hardware,software, firmware, middleware, microcode, hardware descriptionlanguages, or any combination thereof. When implemented in software,firmware, middleware or microcode, the program code or code segments toperform the necessary tasks may be stored in a machine or computerreadable medium. A code segment may represent a procedure, a function, asubprogram, a program, a routine, a subroutine, a module, program code,a software package, a class, or any combination of instructions, datastructures, program statements, and the like.

The term “computer system” as used herein refers to any typeinterconnected electronic devices, computer devices, or componentsthereof. Additionally, the term “computer system” and/or “system” mayrefer to various components of a computer that are communicativelycoupled with one another. Furthermore, the term “computer system” and/or“system” may refer to multiple computer devices and/or multiplecomputing systems that are communicatively coupled with one another andconfigured to share computing and/or networking resources. As usedherein, the term “mobile device” may be considered synonymous to, andmay hereafter be occasionally referred to, as a client, mobile, mobileunit, mobile terminal, mobile station, mobile user, user equipment (UE),user terminal, subscriber, user, remote station, access agent, useragent, receiver, etc., and may describe a remote user of networkresources in a communications network. Furthermore, the term “mobiledevice” may include any type of wireless device such as consumerelectronics devices, smart phones, tablet personal computers, wearablecomputing devices, personal digital assistants (PDAs), laptop computers,and/or any other like physical computing device that is able to connectto a communications network.

As used herein, the term “network element”, may be considered synonymousto and/or referred to as a networked computer, networking hardware,network equipment, router, switch, hub, bridge, gateway, and/or otherlike device. The term “network element” may describe a physicalcomputing device of a wired or wireless communication network that isconfigured to host a client device and the like. Furthermore, the term“network element” may describe equipment that provides radio basebandfunctions for data and/or voice connectivity between a network and oneor more users.

Example embodiments disclosed herein provide systems and methods forbringing a user experience and transaction security aspects of aphysical point of sale (POS) terminal or other like card-presenttransactions to card-not-present transactions, such as onlinetransactions, phone-order transactions, and/or mail-order transactions.Embodiments provide a trusted eCommerce payment mechanism, referred toas a virtual POS (vPOS) terminal or eCommerce POS (ePOS) terminal thatcombines secure payment credentials containment with capabilities toauthenticate the owner of the credentials, and asserts the credentialsduring an online transaction. The embodiments herein models EMV Chip andpersonal identification number (PIN) transactions, using the concept ofan online PIN to effect release of provisioned chip data. Allowscard-present information to be presented at time of transaction, whichmay include, for example, a Primary Account Number (PAN) (or tokenizedPAN), discretionary data, one or more cryptograms (e.g., applicationcryptogram (AC), Application Authentication Cryptogram (AAC),Authorization Request Cryptogram (ARQC), Authorization ResponseCryptogram (ARPC), etc.), and the like. The example embodiments allowusers to remain in control of payment credentials duringcard-not-present transactions. For example, most online payment methodsrequire users to entrust their account and/or banking information to anonline service provider, such as an online payment system, online moneytransfer service, digital wallet service, and/or other like entities.Unlike the typical online payment methods, the example embodiments allowusers to maintain their own payment credentials, whether stored locallywith a trusted execution environment of their own computing device orstored within a trusted cloud computing environment, and provide thepayment credentials to a merchant in encrypted form (or without havingto share the payment credentials in an unencrypted form). Furthermore,unlike digital wallet services (e.g., ApplePay®, Visa Checkout®, etc.),various example embodiments, may not require a server-side digitalwallet (i.e., a thin wallet) to be created and/or maintained on a serverfor each user.

The example embodiments provide a trusted execution environment on, orembedded in, a computing device, which includes a virtual POS terminalinstead of requiring a separate standalone physical POS terminal forswiping payment cards and/or entering payment card information. Invarious embodiments, the trusted execution environment may include oneor more processors, which are separate from an application processor ofthe computing device, to process POS transactions. In other embodiments,the trusted execution environment may be provided as a new mode ofexecution on an existing processor. In some embodiments, the trustedexecution environment may be provided as a cloud computing service thatis separate from the user's computing devices.

In various example embodiments, the trusted execution environment alsoincludes the various payment credentials, which may indicate one or moremethods of payment associated with a user, such as credit cardinformation, bank account information, and the like. When a merchantinitiates a payment request, such as after a user performs an onlinecheckout process, the virtual POS terminal in the trusted executionenvironment may perform various tasks that a standalone physical POSterminal may perform, such as PIN authorization, transaction settlementauthorization, and the like. In addition to the typical functionality ofa standalone physical POS terminal, example embodiments provide thateach payment credential may indicate its own requirements forauthenticating entities and/or processing a POS transaction.

Furthermore, according to various example embodiments, the virtual POSterminal may be accessible through a POS user interface (UI) or POSclient. Additionally, a merchant may have its own POS system that allowsthe user or merchant to enter the user's cellphone number to initiate atransaction. For example, a web-based store may provide a UI that allowsa user to directly access the virtual POS terminal via the user's ownPOS UI that is rendered in the user's web browser. In this way, the usermay be able to provide payment using one or more payment credentialswithout entering payment information and/or authentication informationinto a web-based UI. By way of another example, a telephone ormail-order merchant may acquire payment from a user by entering theuser's cellphone number into their own POS system rather than requiringthe user to dictate payment card information and/or cardholderauthentication information over the phone. The merchant's POS system mayeither call the user's cellphone or send a text message to thecellphone, which may initiate the POS transaction, and the user may usethe POS UI to select a payment credential for processing the POStransaction.

Referring now to the figures. FIG. 1 shows an arrangement 100 in which apoint of sale (POS) transaction may be processed using the virtual POSterminal 120 of the present disclosure, in accordance with variousexample embodiments. As shown in FIG. 1, arrangement 100 may includecomputing system 105, merchant domain 130, payment acquiring service145, messaging service 160, and network connections (or “links,”“channels,” or the like) 150 (e.g., including links 150-1 to 150-7 inFIG. 1). Additionally, computing system 105 may include POS userinterface (UI) module 110 and Trusted Compute resources (e.g., trustedexecution environment (TEE) 115). The trusted execution environment mayinclude virtual POS terminal 120 (also referred to as “vPOS 120,” “ePOS120,” or the like) and payment credential database (DB) 125. As usedherein, a “POS terminal” may also be referred to as a Card AcceptanceDevice (CAD) or Payment Acceptance Device (PAD). Furthermore, themerchant domain may include a cloud POS service 135 and a merchantservice provider platform 140 (also referred to as “merchant 140”).

Computing system 105 may be physical hardware device capable ofcommunicating with a one or more other hardware computing devices (e.g.,merchant 140, one or more devices associated with cloud POS service 135,one or more associated databases (not shown), and the like) via acommunications interface, such that computing system 105 is able toreceive one or more signals and/or data streams from the other hardwarecomputing devices. As shown by FIG. 1, the computing system 105includes, inter alia, a TEE 115. An Execution Environment (EE), as usedherein, is a set of hardware and software components providingfacilities that support running of client applications (CAs). Asexamples, an EE may include a hardware processing device; a set ofconnections between the processing device and other hardware resources;a physical volatile memory; a physical non-volatile memory; andperipheral interfaces. In addition to the TEE 115, the computing system115 also includes a Rich EE (REE), which is an execution environmentcomprising at least one Rich (device) operating system (OS) and one ormore other components of the computing system 105 (e.g., SoCs, otherdiscrete components/hardware elements, firmware, and software) thatexecute, host, and support the rich OS. The rich OS a high-level OS witha rich capability set that allows consumers/users to download and runapplications. Examples of rich operating systems include Microsoft®Windows®, Apple® macOS® and iOS®, Google® Android®, Linux®, Symbian OS®,and the like. In other words, the REE includes one or more discreteelements included in the computing system 105 excluding a secure elementand/or the TEE 115. The TEE 115 is an EE that runs alongside but isisolated from the REE. The TEE 115 has security capabilities and meetcertain security related requirements. The TEE 115 protects TEE 115assets from general software attacks, defines rigid safeguards as todata and functions that a program can access, and resists a set ofdefined threats.

Computing system 105 may include one or more memory devices and one ormore processors (not shown). Computing system 105 may be designed tosequentially and automatically carry out a sequence of arithmetic orlogical operations; equipped to record/store digital data on a machinereadable medium; and transmit and receive digital data via one or morenetwork devices. Computing system 105 may be a desktop personal computer(PC), a laptop PC, a cellphone and/or smartphone, a tablet personalcomputer, a wearable computing device, a video game console, a digitalmedia player, an in-vehicle infotainment (IVI) and/or an in-carentertainment (ICE) device, a handheld messaging device, a personal dataassistant, an electronic book reader, an augmented reality device, andthe like. It should be noted that the computing system 105 may be anyphysical or logical device capable of recording, storing, and/ortransferring digital data via a connection to a network element.

In various embodiments, the computing system 105 may include a networkinterface (e.g., network interface circuitry 230 described with regardto FIGS. 2-3) configured to connect computing system 105 to one or moreother hardware computing devices wirelessly via a transmitter and areceiver (or optionally a transceiver) and/or via a wired connectionusing a communications port. Computing system 105 is configurable oroperable to send/receive data to/from one or more other hardwarecomputing devices, and/or network devices, such as a router, switch,hub, or other like network devices, via the network interface using thewired connection and/or the wireless connection. Computing system 105 isconfigurable or operable to obtain a POS transaction initiation from anetwork element via the network interface, and process a POS transactionbased on the POS transaction initiation according to the exampleembodiments described herein. In embodiments where the computing system105 includes a transmitter/receiver (or alternatively, a transceiver),computing system 105 is configurable or operable to communicate (i.e.,send/receive data to/from a network element and/or other like devices)over the network connections 150 in accordance with one or more wirelesscommunications protocols and/or one or more cellular phonecommunications protocols. For example, computing system 105 isconfigurable or operable to operate in accordance with the Global Systemfor Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE),wideband code division multiple access (WCDMA), code division multipleaccess (CDMA), time division multiple access (TDMA), Bluetooth and/orBluetooth Low Energy (BLE), Wireless Fidelity (Wi-Fi) such as theInstitute of Electrical and Electronics Engineers (IEEE) 802.11a, IEEE802.11b, IEEE 802.11g, IEEE 802.11ac, IEEE 802.11ad, and/or IEEE802.11n, voice over Internet Protocol (VoIP), Wi-MAX, Long TermEvolution (LTE), and/or any other wireless communication protocols,including RF-based, optical, and so forth.

Computing system 105 may include one or more sensors, such as anaccelerometer, gyroscope, gravimeter, magnetometer, and/or another likedevices. The one or more sensors is configurable or operable to detectthe one or more gestures. The one or more gestures may include varioustouches (or combination of touches) applied to a touchscreen of thecomputing system 105, one or more spatial coordinates (or changes inspatial coordinates) of positions and/or orientations of the computingsystem 105. In such embodiments, the computing system 105 may track atiming and/or sequence that one or more gestures are performed, whichmay be used as a gesture-based passcode or password for authenticatingthe user's identity. In some embodiments, the one or more sensors mayinclude a microphone configured to obtain one or more voice commandsissued by a user of the computing system 105, wherein the voice commandsare used to authenticate the user's identity. In such embodiments, theverbal commands may be a passcode and/or the computing system 105 mayperform voice recognition to authenticate the user. In some embodiments,the one or more sensors may include one or more biometric sensors, suchas an infrared heart rate monitoring device, a fingerprint or handprintscanning device, a face and/or an eye scanning device (e.g., a camera orother like image sensor), an electromyography (EMG) device for detectingelectrical patterns associated with a user's muscular contractions, anelectroencephalograph (EEG) device for measuring and/or recordingelectrical signals produced by a user's brain, and the like. In suchembodiments, biometric data detected or sensed by the one or morebiometric sensors may be used to authenticate a user's identity.

Computing system 105 is configurable or operable to run, execute, orotherwise operate one or more applications. According to various exampleembodiments, the one or more applications may include the ePOS client110, the modules within the TEE 115, and/or the TEE 115 itself. The oneor more applications may include native applications, web applications,and hybrid applications. The native applications may be used foroperating the computing system 105, such as using a camera or other likesensor of the computing system 105, GPS functionality of the computingsystem 105, an accelerometer of the computing system 105, cellular phonefunctionality of the computing system 105, and other like functions ofthe computing system 105. Native applications may be platform oroperating system (OS) specific. Here, the term “platform” may refer toan EE within a device or computing system, such as the REE, a secureelement (SE), or TEE 115. Native applications may be developed for aspecific platform using platform-specific development tools, programminglanguages, and the like. Such platform-specific development tools and/orprogramming languages may be provided by a platform vendor. Nativeapplications may be pre-installed on computing system 105 duringmanufacturing, or provided to the computing system 105 by an applicationserver (not shown) via a network. Web applications are applications thatload into a web browser of the computing system 105 in response torequesting the web application from a service provider (e.g., web server135). The web applications may be websites that are designed orcustomized to run on a mobile device by taking into account variousmobile device parameters, such as resource availability, display size,touchscreen input, and the like. In this way, web applications mayprovide an experience that is similar to a native application within aweb browser. Web applications may be any server-side application that isdeveloped with any server-side development tools and/or programminglanguages, such as PHP, Node.js, ASP.NET, and/or any other liketechnology that renders HTML. Hybrid applications may be a hybridbetween native applications and web applications. Hybrid applicationsmay be a standalone, skeletons, or other like application containersthat may load a website within the application container. Hybridapplications may be written using website development tools and/orprogramming languages, such as HTML5, CSS, JavaScript, and the like.Hybrid applications use browser engine of the computing system 105,without using a web browser of the computing system 105, to render awebsite's services locally. Hybrid applications may also access mobiledevice capabilities that are not accessible in web applications, such asthe accelerometer, camera, local storage, and the like. According tovarious embodiments, the ePOS client 110 may be a native application,web application, or a hybrid application. In many embodiments, the TEE115 may be a native application, which may operate in conjunction with aspecialized computer processing device.

There are two client-side peers to the cloud ePOS service 135. One peeris the ePOS client 110, which includes or provides the ePOS userinterface (UI) that renders the online ePOS experience and directs userinteractions with the ePOS system. The other peer is a secure vPOSterminal 120 that interfaces with the embedded payment credentials toobtain their contents and interacts with the cloud ePOS service 135 tointerpret signed authentication assertions (e.g., over connections 150-1and 150-2). Once the user has been successfully authenticated, the vPOSterminal 120 encrypts the obtained payment credentials and transactionsignatures for subsequent transmission to upstream payment processors,such as the payment acquirer service 145 (e.g., via connections 150-2and 150-7).

The client system 105 may operate the ePOS client 110 may be one or moresoftware modules that operate in conjunction with one or more hardwaredevices (e.g., processor 210 as described with regard to FIGS. 2-3) toprovide a user of the computing system 105 with the ability to process aPOS transaction using the computing system 105. In this way, the user ofthe computing system 105 may use the ePOS client 110 to interact withthe vPOS 120 within the TEE 115. The ePOS client 110 may be a clientapplication (or “client”) capable of accessing dynamic content, forexample, by sending appropriate HTTP messages or the like, and inresponse, one or more server-side application(s) may dynamicallygenerate and provide code, scripts, markup language documents, etc., tothe ePOS client 110 to render and display graphical objects within theePOS client 110. The ePOS client 110 may be implemented using one ormore graphical control elements, graphical icons, visual indicators,and/or text based commands. A collection of some or all of the graphicalobjects may be a webpage or application (app) comprising GUIs includingGCEs for accessing and/or interacting with a service providersystem/platform such as messaging service 160, cloud POS service 135,and the like. Additionally or alternatively, the collection of some orall of the graphical objects may comprise GUIs including GCEs foraccessing and/or interacting with the vPOS 120 within the TEE 115. Theaforementioned server-side applications may be developed with anysuitable server-side programming languages or technologies, such as PHP;Java™ based technologies such as Java Servlets, JavaServer Pages (JSP),JavaServer Faces (JSF), etc.; ASP.NET; Ruby or Ruby on Rails; and/or anyother like technology that renders HyperText Markup Language (HTML). Theapplications may be built using a platform-specific and/or proprietarydevelopment tool and/or programming languages. UIs and/or GUIs, andtheir typical functionality are generally well-known, and thus, afurther detailed description of the typical functionality of ePOS client110 is omitted. However, it should be noted that according to variousembodiments, the ePOS client 110 may be the only element that is outsideof the trusted execution environment that is capable of communicatingwith elements within the TEE 115. For example, the ePOS client 110 isconfigurable or operable to communicate with the vPOS 120 as shown inFIG. 1 and as described with regards to FIGS. 13-14. In suchembodiments, the ePOS client 110 may communicate with elements withinthe TEE 115 according to a security application programming interface(API), one or more software guard extension (SGX) instructions, and thelike. Furthermore, the ePOS client 110 is configurable or operable tocommunicate POS transaction related data with the cloud POS service 135as described with regards to FIGS. 13-14.

In one example implementation, the ePOS client 110 may be an HTTPclient, such as a “web browser” (or simply a “browser”) capable ofsending and receiving HTTP messages to and from web and/or applicationservers. In another example implementation, the ePOS client 110 may be abrowser extension or plug-in that operates and/or interacts with anexisting browser. Example browsers include WebKit-based browsers,Microsoft's Internet Explorer browser, Microsoft's Edge browser, Apple'sSafari, Google's Chrome, Opera's browser, Mozilla's Firefox browser,and/or the like. In another example implementation, the ePOS client 110may be a desktop or mobile application that runs directly on thecomputing system 105 without a browser.

In another example implementation, the ePOS client 110 may be anindividual (e.g., stand-alone) application object that operatesindependently of other applications and/or interacts with otherapplications. In these implementations, the ePOS client 110 may operatewithin a security sandbox, VM, container, wrapper, or some other meansfor isolating the ePOS client 110 code runs in isolation from otherapplications. One or more data containers may also be created within thesandbox, VM, container, wrapper, etc.

In another example implementation, the ePOS client 110 is a digitalwallet application (app), which is an app used to store a user's paymentcredentials (e.g., cryptographic private keys and/or public keys) thatare associated with the user's payment instrument and/or paymentcredentials. In embodiments, the wallet app may store the user'scredentials in the PCDB 125. In some implementations, the wallet app maybe a blockchain-based app that stores the user's credentials, and thecredentials are associated with a state of a user's account in theblockchain. The wallet app also allows the user to make transactions,where the public key of the public/private key pair allows other walletsto make payments to the wallet app (e.g., using the wallet's app networkaddress, app/wallet identifier, or the like) and the private key of thepublic/private key pair allows the wallet app spend currency orcryptocurrency stored by the wallet app and/or in the blockchain. Whenthe wallet app is a blockchain app or service, the wallet app enablesthe user to interact with a blockchain or other decentralized ledger ordatabase. The blockchain app may store public and/or private keys, hashgenerators, encryption/decryption algorithms, and/or other like elementsthat can be used to generate blocks to be added to one or moreblockchains. The blockchain app may also include modules, logic, programcode, etc., that allow the blockchain app to validate other blocksgenerated by other user systems before appending those blocks to theblockchain. Additionally, where the Trusted Compute resources is/areimplemented using secure enclaves (discussed infra), the wallet app canalso interface directly with the secure enclave of the ePOS applet 121via the ePOS acceptance driver 122 (discussed infra), a privatetransaction manager, or other like entity, and/or interface withon-chain or off-chain enclaves. The private transaction manager may be asubsystem of a specific blockchain platform/system that implementsprivacy and permissioning, and/or validates blocks for inclusion in ablockchain. Off-chain transactions involve the movement of value outsideof a blockchain, while on-chain transactions modify the blockchain anddepend on the blockchain to validate transactions. Off-chaintransactions rely on other mechanisms to record and validatetransactions, such as payment channels (e.g., Hashed Timelock Contracts(HTLCs) or Lightning Network), sidechains, credit/debit based solutions,trusted third parties, and the like.

The computing system 105 includes Trusted Compute resources thatpreserve data confidentiality, execution integrity and enforces dataaccess policies. The Trusted Compute resources may be used to storecryptographic keys, digital certificates, credentials, paymentcredentials, and/or other sensitive information (e.g., personallyidentifying information (PII)), and could be used to operate someaspects of one or more applications. The Trusted Compute resources canbe implemented using software-based cryptographic security guarantees(e.g., Zero-Knowledge Proofs), user-level or OS-level isolated instances(e.g., “containerization”) or virtualization (e.g., using VMs), TrustedMulti-Party-Compute (MPC) resources, or using TEE 115. In eitherimplementation, applications running on the REE/host platform may becapable of interfacing with the Trusted Compute resources using asuitable (secure) application programming interface (API). Where theTrusted Compute resources is/are implemented using secure enclaves, theapplications running on the REE can also interface directly with theenclave of a secure application or other like entity, and/or interfacewith other enclaves.

In some embodiments, the TEE 115 may be a physical hardware device thatare separate from other components of the computing system 105 (e.g., asdescribed with regard to FIG. 2). In these embodiments, the TEE 115 is ahardware-based technology that executes only validated tasks, producesattested results, provides protection from malicious host software, andensures confidentiality of shared encrypted data. In variousembodiments, TEE 115 may include one or more physically tamper-resistantembedded chipset including processors (e.g., trusted processing core(s),trusted crypto accelerators, etc.) and memory devices (e.g., trustedRAM, trusted ROM, etc.) that communicate with an REE (e.g., hostplatform, application circuitry, etc.) of the computing system 105. Insuch embodiments, applications that are not within the TEE 115 (e.g.,ePOS client 110) may communicate with the physically tamper-resistantembedded processors and memory devices via a security (secure) API orsome other suitable interface such as those discussed in variousGlobalPlatform® TEE API standards such as GlobalPlatform, TEE Client APISpecification v1.0 (July 2010); GlobalPlatform, TEE Internal Core APISpecification v1.2.1 (May 2019); GlobalPlatform, TEE Secure Element APIv1.1.1 (November 2016); and the like. In various embodiments, the TEE115 may include a secure cryptoprocessor, which is a dedicated computeron a chip or a microprocessor designed to secure hardware by integratingcryptographic keys into devices and/or components of the computingsystem 105. In such embodiments, the TEE 115 may operate in accordancewith the International Organization for Standardization (ISO) andInternational Electrotechnical Commission (IEC) specification ISO/IEC11889:2009. In some embodiments, the TEE 115 may have an architecture inaccordance with the GlobalPlatform, TEE System Architecture standardversion 1.2 (November 2018). Examples TEEs 115 may include a Desktop andmobile Architecture Hardware (DASH) compliant Network Interface Card(NIC), Intel® Management/Manageability Engine, Intel® Converged SecurityEngine (CSE) or a Converged Security Management/Manageability Engine(CSME), a financial-grade Secure Element microcontroller, TrustedExecution Engine (TXE) provided by Intel® each of which may operate inconjunction with Intel® Active Management Technology (AMT) and/or Intel®vPro™ Technology; AMD® Platform Security coProcessor (PSP), AMD® PROA-Series Accelerated Processing Unit (APU) with DASH manageability,Apple® Secure Enclave coprocessor; IBM® Crypto Express3®, IBM® 4807,4808, 4809, and/or 4765 Cryptographic Coprocessors, IBM® BaseboardManagement Controller (BMC) with Intelligent Platform ManagementInterface (IPMI), Dell™ Remote Assistant Card II (DRAC II), integratedDell™ Remote Assistant Card (iDRAC), and the like. An example of suchembodiments is shown and described with regards to FIG. 2.

The TEE 115 is not constrained to an embedded platform or subsystem, andin various embodiments, the TEE 115 may be implemented as access cardcircuitry including, for example, an integrated circuit card (ICC) (alsoreferred to as a “chip card” or “smart card”), universal ICC (UICC),Subscriber Identity Module (SIM) card, embedded UICC (eUICC), aform-factor secure element (e.g. SD cards, smart microSDs, USB tokens,etc.), and/or the like. In these embodiments, the access card circuitrycontains the ePOS acceptance driver 122 and ePOS applet 121 (discussedinfra). Such embodiments allow the same payment instrument to be used inmultiple platforms such as desktop computers, laptops, tablets,smartphones, and the like. In some implementations, the access card isremovable or detachable security circuitry (e.g., smart card, UICC, SIMcard, etc.), and the client system 105 may include a card reader or cardslot that is an input device configured to accept the access card (e.g.,usually card shaped) and reads data from the access card's storagemedium. Such access cards are usually implemented as a plastic (e.g.,PVC) card containing semiconductors and embedded contacts, which can beinserted into and communicatively coupled with corresponding contacts inthe card reader. In some implementations, the access card circuitry isnon-removable access card (e.g., eUICC, SoC-based secure element, etc.),where the access card circuitry is embedded on a motherboard of thecomputing system 105 or on some other chip or component in the computingsystem 105. In either implementation, the access card may performvarious access card functions, such as those defined by ISO/IEC 7816,European Telecommunications Standards Institute (ETSI) technicalstandard (TS) 102 221, ETSI TS 102 225, ETSI TS 102 226, ETSI TS 102241, ETSI TS 102 600, 3GPP TS 31.101, 3GPP TS 31.116, 3GPP TS 31.121,3GPP TS 31.220, 3GPP TS 31.828, Groupe Speciale Mobile Association(GSMA), “Remote Provisioning Architecture for Embedded UICC,” TS version3.0, 30 Sep. 2015, and/or any other like standards. Additionally, theaccess card (e.g., SIM card) may securely stores access networkinformation (e.g., an international mobile subscriber identity (IMSI)number and related keys or access credentials) which is used to identifyand authenticate subscribers using radio equipment (e.g., smartphones,satellite phones, tablets, wearables, etc.). The access networkinformation (or SIM) is registered and activated by a mobile networkoperator (MNO), and the access network information is then used toauthenticate the subscriber during a connection or session establishmentprocedure.

In other embodiments, the TEE 115 may be one or more software modulesthat operate in conjunction with one or more hardware devices (e.g., asdescribed with regard to FIG. 3) to carry out secure operations and/orcontrol the storage and use of personal and/or confidential data. Inthese embodiments, the TEE 115 may be one or more “enclaves” (alsoreferred to as “secure enclaves”) within the memory of the computingsystem 105. An “enclave” is an instantiation of trusted computeresources within a hardware based environment, such as the REE (e.g.,host platform, application processor circuitry) or within ahardware-based TEE 115. For purposes of the present disclosure, theterms “TEE” and “enclave” may be used interchangeably. Secure enclavesmay be isolated regions of code and/or data within the address space ofa secure application. In most embodiments, only code executed within asecure enclave may access data within the same secure enclave, and thesecure enclave may only be accessible using the secure application, andother applications may access the secure enclave via the secureapplication. Certain hardware based enclaves allow multiple instances ofenclaves to execute concurrently. Examples of the secure enclave-basedTEE 115 may include secure enclaves defined using the Intel® SoftwareGuard Extensions (Intel® SGX), Keystone Enclaves provided by Oasis Labs™secure/trusted zones using ARM® TrustZone® hardware security extensions,and/or the like. An example of such embodiments is shown and describedwith regards to FIG. 3. Other aspects of security hardening, hardwareroots-of-trust, and trusted or protected operations may also beimplemented in the device 105 through the TEE 115 and/or the processorcircuitry of the device 105.

The TEE 115 operates a Trusted OS, which is an OS running in the TEE 115that is designed using security based design techniques to enable theTEE 115. The trusted OS provides TEE Internal APIs to TrustedApplications (TAs) and a proprietary methods to enable a TEE Client APIto interface with applications operating within other EEs, such as thePOS client 110 operating within the REEs. TAs are applications that runinside the TEE 115 that provide security related functionality to CAsoutside of the TEE 115 or to other TAs inside the TEE 115. The TAscommunicate with the rest of the system via APIs exposed by Trusted OScomponents. TEE internal APIs define the fundamental softwarecapabilities of a TEE 115 and TEE client APIs define interfaces forclient applications to access or communicate with TAs. When a CA createsa session with a TA, the CA connects to an instance of the TA. A TAinstance has physical memory address space which is separated from thephysical memory address space of all other TA instances. A session isused to logically connect multiple commands invoked in a TA. Eachsession has its own state, which contains the session context and thecontext(s) of the task(s) executing the session.

As shown in FIG. 1, the TEE 115 includes vPOS 120 and payment credentialdatabase (DB) 125, which are TAs within the TEE 115. The vPOS 120aggregates payment instrument(s) and certain acquiring elements of POSterminals (e.g., CADs, PADs, etc.) within a single platform (e.g., theTEE 115). The vPOS 120 may be one or more software element, engine,applet, modules, and/or other like collection of functions that operatein conjunction with one or more hardware devices (e.g., processorcircuitry 310 as described with regard to FIG. 2, processor circuitry210 as described with regard to FIG. 3, and the like) to interface withembedded payment credentials to obtain payment credential information,and interact with the ePOS client 110 and/or other like secureapplications to obtain user inputs and information from the cloud POSservice 135. The vPOS 120 may also validate and/or decrypt the userinputs and the information received from the cloud POS service 135 inorder to authenticate a user of the computing system 105 and/or themerchant 140. Once a user has been successfully authenticated, the vPOS120 may encrypt the obtained payment credential information and/ortransaction signatures for subsequent transmission to an upstreampayment processor (e.g., payment acquiring service 145). Furthermore,the vPOS 120 may generate POS transaction messages (which may becommunicated via the ePOS client 110) in accordance with ISO 8583, whichdefines a standard for systems that exchange electronic transactionsmade by cardholders using payment cards.

Payment credential database (PCDB) 125 may be a hardware device orsystem for storing payment credentials and payment credential-relatedinformation for a plurality of payment credentials. The PCDB 125 mayalso be referred to as a “payment credential storage unit,” “paymentsystem environment” (PSE), or the like. In various embodiments, thepayment credentials may be associated with a payment card issued tousers for paying for goods and services (e.g., a credit card, chargecard, debit card, electronic benefits transfer (EBT) cards, etc.). Thepayment credentials may be a digital/electronic version of a physicalpayment card, or the payment credentials may be digital/electronicpayment credentials. The PCDB 125 may also store cardholder data orother like sensitive information belonging to an authorized user of apayment card, which may include a cardholder name, billing address,shipping address, payment card number, PAN, PIN, verification codes,security questions and answers (e.g., cardholder birthdate, mother'smaiden name, etc.), and the like. Furthermore, the PCDB 125 may storepayment credentials and authorization information in accordance with EMV(Europay, MasterCard, and Visa) standards, which define worldwideinteroperability and acceptance standards for secure card-present andcard-not-present transactions. Moreover, in some embodiments, the PCDB125 may store virtual currency information (e.g., Linden Dollars tradedin the virtual online community Second Life®, one or more currenciesexchanged in the massively multiplayer online role-playing game (MMORPG)World of Warcraft®, Amazon Coins®, Nintendo Points®, Facebook® Credits,frequent flyer miles, brick-and-mortar store rewards points, etc.),cryptocurrency information (e.g., bitcoins, litecoins, etc.) and/orother like information used as a medium of exchange. In suchembodiments, the payment credentials stored in the PCDB 125 may includeone or more digital currency wallets (e.g., a bitcoin wallet, etc.)and/or any other like mechanism for storing information necessary toaccount for digital currency transactions. In some embodiments, the PCDB125 may store a Data Object List (DOL) for each payment credential. TheDOLs specify the data that a corresponding credential applet 121 expectsas inputs and will provide as (signed) outputs during each step of thetransaction processing procedure/protocol, as well as the format for thedata. The DOLs indicate the various data elements for each part of atransaction, the format and/or arrangement of the data elements to beused for each part of the transaction, and which data elements should besigned or encrypted. Example data elements include the ApplicationTransaction Counter (ATC), transaction amount(s), currency type(s),country code, financial institution information, and payment credentialor credential applet-chosen nonces.

PCDB 125 may include one or more relational database management systems(RDBMS) one or more object database management systems (ODBMS), acolumn-oriented DBMS, correlation database DBMS, and the like. Accordingto various example embodiments, the PCDB 125 may be stored on orotherwise associated with one or more data storage devices. These datastorage devices may include at least one of a non-volatile random-accessmemory (NVRAM) device, a read-only memory (ROM) device, a flash memorydevice, a solid state drive (SSD), and/or other like data storagedevices. In various embodiments, PCDB 125 may be accessed by the vPOS120 such that the vPOS 120 may query the PCDB 125 to obtain paymentcredential information and/or store payment credential information inthe PCDB 125. In some embodiments, PCDB 125 may be physically and/orlogically divided into multiple databases, while in other embodiments,the PCDB 125 may be a single database that resides on one physicalhardware data storage device.

The TEE 115 may also include one or more Security Domains (SDs) (notshown by FIG. 1). An SD is an on-device representative entity of anAuthority in the TEE 115. SDs are responsible for the control ofadministration operations, and are used to perform the provisioning ofTEE properties and manage the life cycle of TAs. An Authority is anentity or actor that grants permission to perform a specific set ofactions, such as the cloud POS service 135, the merchant 140, thepayment acquiring service 145, or the auth service 170. The SDs allowthe device 105 to be managed by the associated Authority and can then beplaced in in either a secured state (e.g., “TEE_SECURED”) or a lockedstate (e.g., “TEE_LOCKED”). In the secured state, the TEE 115 has beenconfigured with at least one SD including personalization, keys, anddata in order to perform administration operations. The locked statedisables new accesses from CAs to any TAs within the TEE 115. In thelocked state, any attempt by a CA to open a new session with a TA isrejected and provided with an error message/code. Once the TEE 115 islocked, only an SD having the necessary privileges is allowed to unlockthe TEE 115. The unlock operation switches the TEE 115 from the lockedstate back to the secure state. Similarly, the SD may be in anaccessible state or a block state. In the accessible state, the SD isfully operational, and can be used by CAs (active state) or istemporarily suspended to perform some maintenance operations (restrictedstate). In the blocked state, the SD can neither be used noradministrated until it is unblocked. The TAs may be in an active stateor inactive state. In the active state, a TA can be accessed and used byCAs, and if the TEE is in the locked state, the TA is temporarilysuspended to perform some maintenance operations. In the inactive state,the TA is directly controlled by an associated SD and can neither beused nor administrated until its SD is unblocked.

Merchant domain 130 may be a collection of devices, systems, and/orservices that are utilized by a merchant (e.g., merchant 140) to engagewith ecommerce-related activities. As shown merchant domain 130 mayinclude merchant server 140 and cloud POS service 135.

Merchant server 140 (also referred to as “merchant 140”) may be one ormore hardware computing devices that may include one or more servers orother like network elements for providing one or more services. The oneor more services may include selling products and/or services, providingan online market place for the purchase and/or sale of products andservices, mining demographic data, online marketing, and/or other likeecommerce-related services. In this regard, the merchant 140 may engagewith a user of the computing system 105 to sell products and/or servicesto the user, and utilize the cloud POS service 135 to initiate a POStransaction with the computing system 105. The merchant server 140 mayinclude an operating system that may provide executable programinstructions for the general administration and operation of merchantserver 140, and may include a computer-readable medium storinginstructions that, when executed by a processor of the merchant server140, may allow the merchant server 140 to perform its intendedfunctions. Suitable implementations for the operating system and generalfunctionality of the servers are known or commercially available, andare readily implemented by persons having ordinary skill in the art,particularly in light of the disclosure herein. Furthermore, it shouldbe understood that the merchant 140 may not be required and theapplications and software components discussed herein may be executed onany appropriate device or host machine.

Cloud POS service 135 may be one or more hardware computing devices thatmay include one or more servers or other like network elements forproviding one or more services. The one or more services provided by thecloud POS service 135 may include initiating a POS transaction with aclient device that is enabled to process POS transactions (e.g.,computing system 105), authenticating payment information and/or useridentity information, and providing POS transaction-related informationto the computing system 105 to process a POS transaction. In thisregard, cloud POS service 135 may communicate data (i.e., transmit andreceive) with ePOS client 110, and thus, may communicate to vPOS 120securely and indirectly through the ePOS client 110. Additionally, thecloud POS service 135 may communicate data (i.e., transmit and receive)with the merchant 140 and/or the payment acquiring service 145 purposesof processing POS transactions. In order to communicate with the ePOSclient 110, the merchant 140, and/or the payment acquiring service 145,the cloud POS service 135 may generate POS transaction messages (whichmay be communicated to the ePOS client 110) in accordance with ISO 8583,which defines a standard for systems that exchange electronictransactions made by cardholders using payment cards.

The cloud POS service 135 may be integrated with a payment system thatis implemented by the merchant 140, and may capture POS transactiondetails for analysis and reporting to the merchant 140. In someembodiments, the cloud POS service 135 may be a standalone service suchthat the cloud POS service 135 is implemented separately from themerchant domain 130. In this way, the cloud POS service 135 may behosted by an independent entity that may provide the cloud POS service135 to a plurality of merchant services simultaneously. It should benoted that typical digital wallet services and/or online money transferservices may be hosted by an independent entity that provides theirservices to a plurality of merchants simultaneously. However, unlike thetypical digital wallet services and/or online money transfer services,in various embodiments the cloud POS service 135 may not have to retainuser payment information and user identification information. Instead,the cloud POS service 135 may allow users to retain possession andcontrol of their personal account information and personally identifyinginformation. Therefore, the cloud POS service 135 may provide networkand computational resource efficiencies while also providing userprivacy protections. Furthermore, because typical card-not-presenttransactions usually have a higher rate of fraud, merchants are usuallycharged higher bank processing fees and/or are required to absorb costsassociated with data breaches and/or fraudulent transactions. Therefore,merchants are usually responsible for processing payments and providingsecurity measures for handling payment information for typicalcard-not-present transaction. Accordingly, merchants that utilize thecloud POS service 135 could end up paying a lower transaction fee toprocess payments through the cloud POS service 135 (including the vPOS120) rather than processing payments on their own.

The cloud POS service 135 may include an operating system that mayprovide executable program instructions for the general administrationand operation of payment acquiring service 145, and may include acomputer-readable medium storing instructions that, when executed by aprocessor of the application server 130, may allow the payment acquiringservice 145 to perform its intended functions. Suitable implementationsfor the operating system and general functionality of the servers areknown or commercially available, and are readily implemented by personshaving ordinary skill in the art, particularly in light of thedisclosure herein. Furthermore, it should be understood that the paymentacquiring service 145 may not be required and the applications andsoftware components discussed herein may be executed on any appropriatedevice or host machine.

In embodiments, a payment kernel (e.g., the algorithm dictating theprotocol interaction with the payment instrument) may run in the cloud135 (not shown by FIG. 1) while the acceptance endpoint (e.g., ePOSapplet(s) 121) runs within the confines of the secure TEE 115 platform.In some embodiments, the payment kernel maintains trusted statesynchronization with the acceptance endpoint. This may be done over anetwork connection 150 or with an associated SD in the TEE 115 (e.g.,the TEE_SECURED state, SD blocked state, or TA inactive state). The TEE115 includes one or more payment credentials (e.g., in PCDB 125), andalso one or more ePOS applets 121 (also referred to as “credentialapplets” or the like). The ePOS applets 121 are responsible forproviding internal and external access to the secure element instance(e.g., Trusted OS instance), processing account data, performingcardholder verification, and the like. The ePOS applets 121 may beimplemented as widgets such as plug-ins, applets, desk accessories, orother like software component(s). A widget (applet) is a relativelysmall application that performs a specific task and runs within a secureOS, dedicated widget engine, or as part of a larger application. Awidget engine is the software platform on which desktop or web widgetsrun. In some embodiments, the ePOS applet 121 may be implemented as asmartcard payment applet compatible with EMV standards, GlobalPlatformstandards, and the like. The TEE 115 may include and/or operate aTrusted OS such as a secure OS, real-time OS (RTOS), widget engine, VMmanager, or other like software element that that controls and managesaccess to the TEE 115 and/or the ePOS applet 121. A Trusted OS is anoperating system running in the TEE providing a TEE internal core API toTAs. In one example implementation, the Trusted OS may be the Java Card™OpenPlatform (JCOP), which is a standardized smart card OS. The JCOP mayinclude a Java Card™ Virtual Machine (JCVM) and/or implement a JavaCard™ Runtime Environment (JCRE), which allow Java applets to run onUICCs and eUICCs. In other embodiments, the Trusted OS may be a nativeOS, which is a proprietary vendor-specific OS. In either embodiment, theTrusted OS may implement a profile loader (also referred to as a“profile installer” and/or a “profile manager”) for installing andmanaging provisioned profiles, applets, and/or payment credentials. Invarious embodiments, vPOS 120 may include multiple ePOS applets 121 thatare selectable and applied at the time of committing to a transaction(e.g., making payment).

The ePOS applet(s) 121 is/are personalized to contain the paymentcredentials in a same or similar manner to an applet contained on astandard payment card or standard access card. The personalization maybe provided using, for example, Store Data data grouping identifiers(DGIs) and/or secure channel protocols. Personalization may also takeplace according to the EMV Card Personalization Specification version1.0 (June 2003) and/or other like specifications. When there is arequest for payment, the cloud payment kernel, interacting with theplatform payment acceptance endpoint (e.g., TEE 115), communicates withthe embedded ePOS applet 121 to consummate the payment transaction. Fromthe perspective of the payment acquiring service 145, the transaction isidentical to a payment transaction initiated between a conventional POSterminal interacting with a customer payment card. This providesassurance that the actual card is present at the time of transactionrather than a falsified card or malicious code.

Another aspect of a secure transactions is to prove that the authorizedcardholder is present at the time of transaction. In generalface-to-face payment card transactions, there are four levels oftransaction security associated with cardholder presence. In increasingconfidence of cardholder authenticity these include: No Verification,Signature, Local PIN, and Online PIN. In various embodiments, individualconfidence levels of user authentication (e.g., depending on platformcapabilities) are mapped to each of the cardholder authenticity fourlevels, providing compatibility with existing EMV user verificationmethods. In other embodiments, multiple confidence levels may be mappedto the same cardholder authenticity level to provide a more granularapproach to verifying user authenticity locally at the computing system105. The combination of card authenticity coupled with credentialauthentication yields assurances that are compliant with traditionalcard-not-present situations. When such assurances are successfullyasserted, merchants 130 benefit from decreased fraud and lower cost ofpayment acceptance, thereby reducing overall network and computationalresource consumption. Payment card issuers and processing networks alsobenefit from increased transaction volume since there are significantnumbers of people who refuse to participate in eCommerce due to fearssurrounding fraud and/or identity theft. Moreover, these embodiments maybe applied to other scenarios, such as preventing SIM swapping and/orSIM hijacking.

In various embodiments, the ePOS acceptance driver 122 provides a bridgeinterface between the cloud ePOS kernel in cloud 135 and the ePOS applet121 executing inside of the TEE 115. In some embodiments, the ePOSdriver 122 includes terminal logic and/or device pairing logic tomaintain trusted state synchronization with the POS cloud 135. Securityof the transaction is provided by the ePOS acceptance driver 122, whichuses transaction-specific encryption to provide confidentiality ofsensitive transaction elements. One example approach combinesformat-preserving-encryption with transaction-specific keying availablewith standards such as ANSI X9.24-1 (DUKPT) to provide transaction dataconfidentiality. Other encryption schemes may be used in otherembodiments.

FIG. 1 also shows elements of the ePOS client 110, which supports bothuser authentication mechanisms, plus ePOS logic 113 to support paymentinteractions and user interfaces. The ePOS logic 113 is factored betweenthe merchant 140 and the credential hosting environment (e.g., vPOS120). The authentication mechanisms may be referred to as “cardholderverification methods” or “CVMs” in EMV terminology. there are threeoptions for PIN-based cardholder verification: online PIN where the PINis provided to the cloud POS service 135 and/or the auth service 170 forauthentication; offline unencrypted PIN where the PIN is sent to theePOS applet 121 without being encrypted; and offline encrypted PIN wherethe PIN is encrypted before being sent to the ePOS applet 121. Inconventional CVM, the access card is only involved in cardholderverification when offline PIN is used, and online PIN verification isperformed using a protocol between the conventional POS terminal and thefinancial institution (e.g. service 145). If an access card supportsboth online and offline PIN CVMs, the issuing financial institutionusually has to have mechanisms in place to ensure that the two PINs aresynchronized. Synchronization is important, because when cardholders areasked to enter a PIN, they do not know whether they should enter theiroffline PIN or online PIN. By contrast, in various embodiments, the vPOS120 is involved in online PIN verification at least to securely pass thePIN to the cloud 135 and/or auth service 170, which is more secure thanconventional CVM. Although the present disclosure discusses using a PINfor user authentication/verification, which is usually four, six, ortwelve digits, it should be noted that a passcode, password, biometricdata, physical hardware mechanism, and/or any other type ofauthentication means may be used in place of a PIN in variousembodiments.

Locally controlled (offline) user authentication is provided through thesecure PIN client 112, which provides a PIN (e.g., input by the user) tothe ePOS driver 122 over interface 119. In these embodiments, the PINare verified directly by credential applet 121. For plaintext(unencrypted) PIN verification, the PIN code is sent to the ePOS applet121 via the ePOS driver 122, and the ePOS applet 121 returns anunauthenticated response to the secure PIN client 112 via the ePOSdriver 122. The unauthenticated response indicates whether the PIN wascorrect or how many failed PIN attempts there are left before the ePOSapplet 121 blocks access to the selected payment credential. Additionalor alternative security measures may be taken when the maximum number ofattempts is reached. If encrypted PIN verification is used, the ePOSapplet 121 requests a nonce from the ePOS driver 122 and/or the securePIN client 112. The ePOS applet 121 uses a public key of associated withthe selected payment credential, encrypts the PIN together with thenonce and some random padding created by the ePOS applet 121 (e.g.,using a suitable random number generator, hash function, etc.). A resultof the verification may be returned to the PIN client 112 and displayedto the user in some embodiments.

Online user authentication is managed through an external authentication(auth) service 170 via the auth client 111. In these embodiments, theonline PIN is verified by auth service 170, and online serviceauthentication assertions are received via connection 150-1 forverification by the ePOS 121. In some embodiments, the merchant 130 thathosts the ePOS payment kernel (e.g., within cloud POS service 135 or insome other merchant 130 system or platform), and who is also a relyingparty to the auth service 170 is responsible for providing levels ofuser authentication relevant to the value of the transaction. In someembodiments, the auth client 111 provides the online PIN to the authservice 170 via connection 150-5. In some embodiments, the auth client111 provides the online PIN to the cloud POS 135 over connection 150-3,which is then relayed to the auth service 170 over connection 150-4. Inone implementation, the ‘what you see is what you get’ (WYSIWYS) digitalsignature techniques may be used to capture and protect the online PINfor verification by the ePOS applet 121. In one example implementation,security of the online PIN entry may be achieved by using Intel®Identity Protection Technology (IPT), which uses Protected TransactionDisplay (PTD) to protect Public Key Infrastructure (PKI) certificatesand RSA keys with a PIN. The PTD may be used to confirm transactionamounts and/or other transaction information.

The user authentication mechanisms (e.g., auth client 111 and/or securePIN client 112) can include multiple and varying factors, including, butnot limited to user name/ID and password, PIN, location-based,network-based (e.g., virtual private network (VPN), etc.) securitytokens, physical authentication devices (e.g., wearable continuousauthentication using a smartwatch or the like, YubiKey® provided byYubico® or the like), and/or biometric data. Additionally oralternatively, authentication strategies based on NIST SP800-63Electronic Authentication Guidelines may be used.

The cloud ePOS kernel is also interconnected to a payment processingnetwork 145 via connection 150-7 between the cloud ePOS service 135 andpayment acquirer service 145. This element understands standard paymentprotocols such as ISO 8583 and the like, common to the paymentprocessing ecosystems. Interactions between the ePOS cloud 135 andclient ePOS elements ensure that data elements are present in thetransaction such that the payment networks 145 comprehend ePOStransactions to be equivalent to card-present payments and/or the like.

In some embodiments, the use of a contactless payment kernel hosted inthe TEE 115 (e.g., a secure enclave) may communicate with the ePOSAcceptance Driver 122, and the ePOS Acceptance Driver 122 may becommunicatively coupled with an NFC controller implemented in thecomputing system 105 (not shown). Such embodiments allow the paymentinstrument to be, or act as, an external contactless card such as anApple Pay® contactless device. In these embodiments, the cloud ePOS 135directs the actions of the client-hosted payment kernel 121 tofacilitate acceptance of existing contactless payment instruments.

As alluded to previously, the strength of user authentication is mappedto an appropriate value of the transaction. This capability is providedby auth service 170. In one example, transaction inputs (e.g., EMVcommands and/or auth service 170 assertions) are conveyed to the vPOS120 via connection 150-1, and transaction outputs (e.g., cardholderauthentication data, ISO 8583 transaction data, EMV responses, paymentcredentials, online PIN block, etc.) are provided to the ePOS cloud 135via connection 150-2. In some implementations, the auth service 170 maybe provided by Intel® True Key (or “You Are the Password” or “YAP”). Forexample, YAP provides scoring levels associated with the strength of agiven authentication. Mapping YAP scoring levels to EMV assurancecategories of No Verification, Signature, Local PIN, or Online PIN,allows ePOS authentication/verification to be used with existing paymentprocessing attributes designed to assert these various levels ofuser/cardholder verification. When combined with EMV metadata elementsthat bind required authentication strength to transaction value, theePOS system 100 provides both card issuers and merchants 130 thecontrols necessary to dynamically manage risk.

The various entities, elements, systems, devices, etc., in arrangement100 are communicatively coupled via various network connections 150(e.g., including connections 150-1 to 150-7 in FIG. 1), which may bepart of any of one or more networks (referred to as “network 150”) thatallow computers to exchange data. Network 150 may include one or morenetwork elements (not shown) capable of physically or logicallyconnecting computers. The network 150 may include any appropriatenetwork, including an intranet, the Internet, a cellular network, alocal area network (LAN), a wide area network (WAN), a personal networkor any other such network or combination thereof. Components used forsuch a system can depend at least in part upon the type of networkand/or environment selected. Protocols and components for communicatingvia such a network are well known and will not be discussed herein indetail. Communication over the network 150 may be enabled by wired orwireless connections, and combinations thereof.

Payment acquiring service 145 may be include one or more physical and/orvirtual computing systems such as one or more servers or other likenetwork elements for providing one or more services. The paymentacquiring service 145 may be a financial institution, bank, and/or otherlike entity or group of entities that is able to process paymentcredential purchases on behalf of a merchant platform (e.g., merchant140). In some embodiments, the payment acquiring service 145 may bereferred to as a “merchant bank”, “acquirer”, and the like. The paymentacquiring service 145 may be contacted by the cloud POS service 135 toauthorize a payment card purchase amount. The payment acquiring service145 may be able to approve or decline a payment credential purchaseamount, and if approved, the payment acquiring service 145 may settlethe transaction by placing the funds into an account associated with themerchant 140. The payment acquiring service 145 may include an operatingsystem that may provide executable program instructions for the generaladministration and operation of payment acquiring service 145, and mayinclude a computer-readable medium storing instructions that, whenexecuted by a processor of the application server 130, may allow thepayment acquiring service 145 to perform its intended functions.Suitable implementations for the operating system and generalfunctionality of the servers are known or commercially available, andare readily implemented by persons having ordinary skill in the art,particularly in light of the disclosure herein.

Messaging service 160 may be one or more hardware computing devices thatmay include one or more servers or other like network elements forproviding one or more services. The messaging service 160 may be aservice that forwards or otherwise provides notifications and/or otherlike messages from third parties to client devices (e.g., computingsystem 105). In such embodiments, the notifications or messages may bepush notifications communicated in accordance with the Push AccessProtocol (PAP), simple mail transfer protocol (SMTP), ExtensibleMessaging and Presence Protocol (XMPP), and/or other like pushcommunication protocols. Such notifications or messages may includeaudio/video messages, text alerts, and/or the like. The messagingservice 160 may be contacted by the cloud POS service 135 to provide aPOS transaction initiation message to the computing system 105 on behalfof the cloud POS service 135. In various embodiments, the messagingservice 160 may be a mobile messaging service, such as Google CloudMessaging (GCM), Apple Push Notification Services and/or NotificationCenter, Windows Push Notification Service (WNS), and/or other likemessaging services. In other embodiments, the messaging service may be aShort Message Service (SMS) Function (SMSF) that sends SMS messages tocellular network subscribers (e.g., computing system 105) on behalf ofcloud POS service 135.

The arrangement 100 may be implemented according to one or more of thefollowing use cases. There are multiple use cases that can benefit fromarrangement 100 and several of these are listed below, although theseuse cases is not an exhaustive list, and the embodiments herein can beemployed for various other use cases.

Use case 1: ecommerce or web-based purchases. According to use case 1,the vPOS 120 may be accessible by rendering the ePOS client 110 in astandard web browser. When the user of the computing system 105 goesthrough an ecommerce checkout process, the user may be asked to make anecommerce payment. At this point, the cloud POS service 135, operatingin conjunction with the ecommerce checkout process provided by themerchant 140, may solicit the POS transaction through the ePOS client110 rendered in the web browser. A variant of use case 1 may includeout-of-band ecommerce transactions, such as those performed on untrustedor otherwise unsecure computing devices. In such instances, when theuser is asked to provide payment, the user may provide a uniqueidentifier (e.g., e.g., mobile phone number, an email address, and/orany other user-related identifier) associated with a computing deviceenable to process POS transactions (e.g., computing system 105) insteadof entering payment information directly into a web browser of anuntrusted computing device. Once the user enters the phone number, emailaddress, etc. of the computing device enabled to process POStransactions the transaction initiation message may be sent to thecomputing system 105 via the cloud POS service 135 and/or messagingservice 160, instructing computing system 105 to process the POStransaction.

Use case 2: mail-order and/or telephone-order purchases. Telephone-ordertransactions traditionally require customers to dictate paymentinformation over the phone to an agent of a merchant in order topurchase a product or service. According to use case 2, a user of thecomputing system 105 may order a product or service over the phone.However, instead of requiring the user to dictate payment informationover the phone, the user may provide a unique identifier (e.g., mobilephone number, an email address, and/or any other user-relatedidentifier) to the merchant 140 (or an agent of the merchant 140). Themerchant 140 (or an agent of the merchant 140) may enter the uniqueidentifier into a merchant terminal that is enabled to interact with thecloud POS service 135, and the cloud POS service 135 and/or messagingservice 160 may send a transaction initiation to the computing system105. The POS transaction may then be processed according to the variousexample embodiments disclosed herein. For mail-order purchases, whichtypically require a customer to write down payment information on apaper order form, the customer may manually write the unique identifieron the paper order form instead of writing payment information and/orauthentication information into the order form. When the order formreaches the merchant 140, the unique identifier may be entered into amerchant terminal enabled to interact with the cloud POS service 135,which may immediately send a transaction initiation to the computingsystem 105 via the cloud POS service 135. When the merchant receivespayment confirmation from the computing system 105, the merchant 140 mayfulfill (e.g., ship) the ordered product or service.

Use case 3: brick-and-mortar purchases. Most brick-and-mortartransactions require customers to enter payment information into astandalone physical POS terminal (also referred to as a credit cardterminal, payment terminal, electronic funds transfer (EFT) POSterminal, etc.) to purchase a product or service. In most cases, thestandalone physical POS terminals allow customers or merchants toinsert, swipe, or manually enter the required payment information.According to use case 3, the user of the computing system 105 mayprovide a unique identifier to a brick-and-mortar store employee, whomay then enter the unique identifier into a merchant terminal enabled tointeract with the cloud POS service 135.

A variant of use case 3 may involve other physical outlets that may nothave a typical standalone physical POS terminal. These other physicaloutlets may include merchants at farmers' markets, trade shows, swapmeets, flea markets, bazaars, conventions, concerts, and the like.Typically, merchants of these other physical outlets may have acomputing device, such as a smartphone or tablet PC, which may mimic orreplace the functionality of the standalone physical POS terminalhardware using a terminal application running on a the computing device.These terminal applications usually require manual entry of paymentinformation, or may operate in conjunction with a peripheral hardwarepayment card reader that can transfer payment information to theterminal application. Such peripheral payment card readers may connectto the merchant's computing device through an audio jack of thecomputing device. Since these terminal applications typically mimic thestandalone physical POS terminals, they often present the same orsimilar security concerns that apply to the standalone physical POSterminals. According to the variant of use case 3, the merchant'scomputing device may include its own POS UI that may interact with thecloud POS service 135, and a user of the computing system 105 maymanually enter or otherwise provide a unique identifier to themerchant's POS UI to initiate the POS transaction via the cloud POSservice 135.

Use case 4: user-initiated donations. In some instances, a user may wishto make a donation or tithe to an entity, such as a non-profitorganization. Rather than requiring the donation recipients to manuallyprocess card requests using standalone physical POS terminals or aterminal application as discussed with regard to use case 3, accordingto use case 4, the ePOS client 110 may allow a user of the computingsystem 105 to initiate and complete payment requests on their own. Invarious embodiments, the donation recipient may deploy a Bluetoothlow-energy (BLE) beacon that broadcasts one or more signals, whichindicate that a POS payment may be made at a physical location. When thecomputing system 105 obtains the one or more BLE signals, the computingsystem 105 may indicate that a POS payment point associated with thedonation recipient is nearby, and the user of the computing system 105may execute the ePOS client 110 to initiate a POS transaction accordingto the example embodiments disclosed herein. It should be noted that avariant of use case 4 may involve deploying BLE beacons inbrick-and-mortar stores or other like physical outlets to facilitate thepurchase of products or services, rather than requiring an employee toperform a checkout process and the like.

Use case 5: Out-of-band eCommerce payments are possible using the ePOSmechanisms described in use case 2, and where a web checkout form offersan out-of-band ePOS payment capability. By entering a mobile phonenumber in the web checkout form, the merchant eCommerce system 140provides a mechanism to redirect the eCommerce payment operation to thecomputing system 105 (e.g., using messaging service 160 or the like).This option is more secure from the perspective of not providing paymentinformation through a computer that may not have secure paymentacceptance capabilities (e.g. a public computer).

Use case 6: protection against SIM hijacking or SIM swapping scams. Atits most basic level, a SIM swap or hijack is a type of account takeoverfraud where an attacker convinces a victim's mobile carrier to switchthe victim's phone number over to a SIM card own by the attacker. Thisallows the attacker to divert incoming messages (e.g., SMS messages) tothe attacker's device so the attacker can easily complete text/SMS-basedtwo-factor authentication to gain access to the victim's online accountsand/or other protected sensitive data or applications. It is conceivablethat this type of fraud could be attempted for the vPOS 120, where anattacker may convince a financial institution to switch or re-provisiona victim's payment credentials to a SIM card or TEE 115 in a deviceowned by the attacker, such as when, the TEE 115 is a UICC, SIM card, orother access card that includes the vPOS 120 and/or PCDB 125. Usually,the contents/data stored by an access card (e.g., SIM card) cannot beperfectly copied/cloned, and therefore, swapping an access card with adifferent physical or virtualized access card would cause anauthentication failure in the backend of the cloud system 135 and/orauth system 170. This is because the original vPOS 120 would maintain atrusted state synchronization (e.g., secured state, blocked state, orinactive state) with the cloud system 135 and/or auth system 170 (or anassociated SD in the TEE 115) that cannot be duplicated with to a new ordifferent access card or TEE 115. In this use case, when the trustedstate synchronization with the cloud system 135 and/or auth system 170is broken, the TEE 115 may deny access to the vPOS 120 (e.g., by placingthe TEE 115 in the locked state) until the trusted (secure) state isreestablished. Additionally or alternatively, a PIN may be set to accessthe vPOS 120, which may be the same or different than the PINs set toaccess individual payment credentials within the vPOS 120. The victim'sPIN(s) may still be maintained in the emulated or stolen SIM. If theaccess card were cloned or stolen and placed in another device, then theattacker attempting to use it would also have to know the victim's PINin order to utilize the stolen SIM and/or vPOS 120. Without the PIN, theoverall authentication of a transaction would fail.

FIG. 2 illustrates the components of the computing system 105, inaccordance with various example embodiments. As shown, computing system105 may include processor circuitry 210, interconnect (IX) 220, networkinterface circuitry (NIC) 230, input/output (I/O) interface circuitry240, memory circuitry 250, and TEE 115. As shown, TEE 115 may includememory 350 and processor circuitry 310. In various embodiments, one ormore of the elements/components not included in the TEE 115 may bereferred to as the REE or “host platform”. The TEE 115 is an executionenvironment that runs alongside but is isolated from the REE. The TEE115 has security capabilities and meet certain security relatedrequirements. The TEE 115 protects TEE 115 assets from general softwareattacks, defines rigid safeguards as to data and functions that aprogram can access, and resists a set of defined threats.

Memory circuitry 250 may be a hardware device configured to store anoperating system 260 and program code for one or more softwarecomponents, such as ePOS client 110 and/or one or more otherapplications. Memory circuitry 250 may be a computer readable storagemedium that generally includes a random access memory (RAM), read onlymemory (ROM), a flash memory device, a solid state disk (SSD), a securedigital (SD) card, and/or other like storage media capable of storingand recording data. The program code and/or software components may alsobe loaded from a separate computer readable storage medium into memorycircuitry 250 using a drive mechanism (not shown). Such separatecomputer readable storage medium may include a memory card, memorystick, removable flash drive, SIM card, and/or other like computerreadable storage medium (not shown). In some embodiments, softwarecomponents may be loaded into memory circuitry 250 via NIC 230, ratherthan via a computer readable storage medium.

Any number of memory devices may be used to provide for a given amountof system memory 250. As examples, the memory may be random accessmemory (RAM) in accordance with a Joint Electron Devices EngineeringCouncil (JEDEC) design such as the DDR or mobile DDR standards (e.g.,LPDDR, LPDDR2, LPDDR3, or LPDDR4). In particular examples, a memorycomponent may comply with a DRAM standard promulgated by JEDEC, such asJESD79F for DDR SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3SDRAM, JESD79-4A for DDR4 SDRAM, JESD209 for Low Power DDR (LPDDR),JESD209-2 for LPDDR2, JESD209-3 for LPDDR3, and JESD209-4 for LPDDR4.Other types of RAM, such as dynamic RAM (DRAM), synchronous DRAM(SDRAM), and/or the like may also be included. Such standards (andsimilar standards) may be referred to as DDR-based standards andcommunication interfaces of the storage devices that implement suchstandards may be referred to as DDR-based interfaces. In variousimplementations, the individual memory devices may be of any number ofdifferent package types such as single die package (SDP), dual diepackage (DDP) or quad die package (Q17P). These devices, in someexamples, may be directly soldered onto a motherboard to provide a lowerprofile solution, while in other examples the devices are configured asone or more memory modules that in turn couple to the motherboard by agiven connector. Any number of other memory implementations may be used,such as other types of memory modules, e.g., dual inline memory modules(DIMMs) of different varieties including but not limited to microDIMMsor MiniDIMMs.

To provide for persistent storage of information such as data,applications, operating systems and so forth, storage device(s) may alsobe included in or coupled with the system 105. In an example, thestorage device(s) may be implemented via a solid-state disk drive (SSDD)and/or high-speed electrically erasable memory (commonly referred to as“flash memory”). Other devices that may be used for the storagedevice(s) include flash memory cards, such as SD cards, microSD cards,XD picture cards, and the like, and USB flash drives. In an example, thememory device may be or may include memory devices that use chalcogenideglass, multi-threshold level NAND flash memory, NOR flash memory, singleor multi-level Phase Change Memory (PCM), a resistive memory, nanowirememory, ferroelectric transistor random access memory (FeTRAM),anti-ferroelectric memory, magnetoresistive random access memory (MRAM)memory that incorporates memristor technology, phase change RAM (PRAM),resistive memory including the metal oxide base, the oxygen vacancy baseand the conductive bridge Random Access Memory (CB-RAM), or spintransfer torque (STT)-MRAM, a spintronic magnetic junction memory baseddevice, a magnetic tunneling junction (MTJ) based device, a Domain Wall(DW) and Spin Orbit Transfer (SOT) based device, a thyristor basedmemory device, or a combination of any of the above, or other memory.The memory circuitry 250 and/or storage circuitry may also incorporatethree-dimensional (3D) cross-point (XPOINT) memories from Intel® andMicron®. In low power implementations, the storage device(s) may beon-die memory or registers associated with the processor circuitry 210.However, in some examples, the storage device(s) may be implementedusing a micro hard disk drive (HDD). Further, any number of newtechnologies may be used for the storage device(s) in addition to, orinstead of, the technologies described, such resistance change memories,phase change memories, holographic memories, or chemical memories, amongothers

During operation, memory circuitry 250 may include operating system 260and ePOS client 110. Operating system 260 may manage computer hardwareand software resources and provide common services for computerprograms. Operating system 260 may include one or more drivers, such asa display driver, sensor drivers (e.g., a camera driver, etc.), audiodrivers, and/or any other like drivers that provide an interface tohardware devices without needing to know the details of the hardwareitself. According to various embodiments, the operating system 260 mayinclude one or more drivers for accessing the TEE 115 thereby enablingePOS client 110 to access hardware functions inside the TEE 115, such asthe vPOS 120, without needing to know the details of the TEE 115 itself.The operating system 260 may be a general purpose operating system or anoperating system specifically written for and tailored to the computingsystem 105.

ePOS client 110 may be a collection of software modules and/or programcode that enables the computing system 105 to access or obtain POStransaction data and/or other like data from the vPOS 120 within the TEE115, and/or operate according to the various example embodiments asdisclosed herein. ePOS client 110 may be a native application, a webapplication, or a hybrid application. In some embodiments, ePOS client110 may be a web application that may be rendered in a web browser ofthe computing system 105.

Processor circuitry 210 is configurable or operable to carry outinstructions of a computer program by performing the basic arithmetical,logical, and input/output operations of the system. The processorcircuitry 210 includes circuitry such as, but not limited to one or moreprocessor cores and one or more of cache memory, low drop-out voltageregulators (LDOs), interrupt controllers, serial interfaces such as SPI,I²C or universal programmable serial interface circuit, real time clock(RTC), timer-counters including interval and watchdog timers, generalpurpose I/O, memory card controllers such as secure digital/multi-mediacard (SD/MMC) or similar, interfaces, mobile industry processorinterface (MIPI) interfaces and Joint Test Access Group (JTAG) testaccess ports. In some implementations, the processor circuitry 210 mayinclude one or more hardware accelerators, which may be microprocessors,programmable processing devices (e.g., FPGA, ASIC, etc.), or the like.The one or more accelerators may include, for example, computer visionand/or deep learning accelerators. In some implementations, theprocessor circuitry 210 may include on-chip memory circuitry, which mayinclude any suitable volatile and/or non-volatile memory, such as DRAM,SRAM, EPROM, EEPROM, Flash memory, solid-state memory, and/or any othertype of memory device technology, such as those discussed herein.

The processor circuitry 210 may include, for example, one or moreprocessor cores (CPUs), application processors, GPUs, RISC processors,Acorn RISC Machine (ARM) processors, CISC processors, one or more DSPs,one or more FPGAs, one or more PLDs, one or more ASICs, one or morebaseband processors, one or more radio-frequency integrated circuits(RFIC), one or more microprocessors or controllers, a multi-coreprocessor, a multithreaded processor, an ultra-low voltage processor, anembedded processor, or any other known processing elements, or anysuitable combination thereof. The processors (or cores) 210 may becoupled with or may include memory/storage and may be configured toexecute instructions stored in the memory/storage to enable variousapplications or operating systems to run on the system 105. Theprocessors (or cores) 210 is configured to operate application softwareto provide a specific service to a user of the system 105. In someembodiments, the processor(s) 210 may be a special-purposeprocessor(s)/controller(s) configured (or configurable) to operateaccording to the various embodiments herein.

As examples, the processor(s) 210 may include an Intel® ArchitectureCore™ based processor such as an i3, an i5, an i7, an i9 basedprocessor; an Intel® microcontroller-based processor such as a Quark™,an Atom™, or other MCU-based processor; Pentium® processor(s), Xeon®processor(s), or another such processor available from Intel®Corporation, Santa Clara, Calif. However, any number other processorsmay be used, such as one or more of Advanced Micro Devices (AMD) Zen®Architecture such as Ryzen® or EPYC® processor(s), AcceleratedProcessing Units (APUs), MxGPUs, Epyc® processor(s), or the like; A5-A12and/or S1-S4 processor(s) from Apple® Inc., Snapdragon™ or Centrig™processor(s) from Qualcomm® Technologies, Inc., Texas Instruments, Inc.®Open Multimedia Applications Platform (OMAP)™ processor(s); a MIPS-baseddesign from MIPS Technologies, Inc. such as MIPS Warrior M-class,Warrior I-class, and Warrior P-class processors; an ARM-based designlicensed from ARM Holdings, Ltd., such as the ARM Cortex-A, Cortex-R,and Cortex-M family of processors; the ThunderX2® provided by Cavium™,Inc.; or the like. In some implementations, the processor(s) 210 may bea part of a system on a chip (SoC), System-in-Package (SiP), amulti-chip package (MCP), and/or the like, in which the processor(s) 210and other components are formed into a single integrated circuit, or asingle package, such as the Edison™ or Galileo™ SoC boards from Intel®Corporation. Other examples of the processor(s) 210 are mentionedelsewhere in the present disclosure.

The processor circuitry 210 may perform a variety of functions for thecomputing system 105 and may process data by executing program code, oneor more software modules, firmware, middleware, microcode, hardwaredescription languages, and/or any other like set of instructions storedin the memory circuitry 250. The program code may be provided toprocessor circuitry 210 by memory circuitry 250 via IX 220, one or moredrive mechanisms (not shown), and/or via NIC 230. In order to performthe variety of functions and data processing operations, the programcode and/or software components may be executed by the processorcircuitry 210. On execution by the processor circuitry 210, theprocessor circuitry 210 may cause computing system 105 to perform thevarious operations and functions delineated by the program code.

For example, in various embodiments, the ePOS client 110 may includevarious modules and/or program code configured to operate (usinghardware and/or software components) to obtain POS transaction data fromthe vPOS 120 and communicate various POS transaction-related data withthe vPOS 120 and/or the cloud POS service 135 as described herein. Oncethe various modules and/or program code of the ePOS client 110 areloaded into memory circuitry 250 and executed by the processor circuitry210, the processor circuitry 210 is configurable or operable to causecomputing system 105 to receive a transaction initiation from the cloudPOS service 135 or other merchant-related terminal; provide a selectedpayment credential to be used to process a POS transaction; provideauthentication parameters to the cloud POS service 135 or othermerchant-related terminal; receive a cryptographic merchant certificatefrom the cloud POS service 135 or other merchant-related terminal, andprovide the cryptographic merchant certificate to the vPOS 120; receivea personal identification (PIN) solicitation from the cloud POS service135 or other merchant-related terminal; provide a user interface toallow a user of the computing system 105 to enter a PIN; receive theinput PIN and provide the inputted PIN to the cloud POS service 135 orother merchant-related terminal; receive updated transaction terms fromthe cloud POS service 135 or other merchant-related terminal; receiveencrypted payment data from the vPOS 120; communicate the encryptedpayment data to the cloud POS service 135 or other merchant-relatedterminal; and/or perform various other functions or combinations offunctions as disclosed herein. While specific modules are describedherein, it should be recognized that, in various embodiments, variousmodules may be combined, separated into separate modules, and/oromitted. Additionally, in various embodiments, one or more modules maybe implemented on separate devices, in separate locations, ordistributed, individually or in sets, across multiple processors,devices, locations, and/or in cloud-computing implementations.

IX 220 is configurable or operable to enable the communication and datatransfer between the processor circuitry 210 and memory circuitry 250.The IX 220 may include any number of technologies, including IndustryStandard Architecture (ISA), extended ISA, inter-integrated circuit(I²C) IX, Serial Peripheral Interface (SPI), point-to-point interfaces,power management bus (PMBus), Peripheral Component Interconnect (PCI),PCI express (PCIe), PCI extended (PCIx), a Small Computer SystemInterface (SCSI) IX, Intel® Ultra Path Interconnect (UPI), Intel®Accelerator Link, Intel® Common Express Link (CXL), Coherent AcceleratorProcessor Interface (CAPI), OpenCAPI, Intel® QuickPath Interconnect(QPI), Intel® Omni-Path Architecture (OPA) IX, RapidIO™ system IXs,Cache Coherent Interconnect for Accelerators (CCIX), Gen-Z ConsortiumIXs, a HyperTransport interconnect, NVLink provided by NVIDIA®, aTime-Trigger Protocol (TTP) system, a FlexRay system, and/or any numberof other IX technologies. The IX 220 may be a proprietary bus, forexample, used in a SoC based system. In some implementations, the IX 220may comprise a high-speed serial bus, parallel bus, internal universalserial bus (USB), Front-Side-Bus (FSB), and/or other suitablecommunication technology for transferring data between components withincomputing system 105 and other like devices.

NIC 230 may be a computer hardware component that connects computingsystem 105 to a computer network (e.g., network 150). NIC 230 mayconnect computing system 105 to a computer network via a wired orwireless connection. NIC 230 may operate in conjunction with a wirelesstransmitter/receiver and/or transceiver (not shown) that is configuredto operate in accordance with one or more wireless standards. Thewireless transmitter/receiver and/or transceiver is configurable oroperable to operate in accordance with a wireless communicationsstandard, such as the IEEE 802.11-2007 standard (802.11), the Bluetoothstandard, and/or any other like wireless standards. The communicationsport is configurable or operable to operate in accordance with a wiredcommunications protocol, such as a serial communications protocol (e.g.,the Universal Serial Bus (USB), FireWire, Serial Digital Interface(SDI), and/or other like serial communications protocols), a parallelcommunications protocol (e.g., IEEE 1284, Computer Automated MeasurementAnd Control (CAMAC), and/or other like parallel communicationsprotocols), and/or a network communications protocol (e.g., Ethernet,token ring, Fiber Distributed Data Interface (FDDI), and/or other likenetwork communications protocols). The NIC 230 may also include one ormore virtual network interfaces configured to operate with ePOS client110 and/or other like applications.

I/O interface circuitry 240 may be a computer hardware component thatprovides communication between the computing system 105 and one or moreother devices. The I/O interface circuitry 240 may include one or moreuser interfaces designed to enable user interaction with the computingsystem 105 and/or peripheral component interfaces designed to provideinteraction between the computing system 105 and one or more peripheralcomponents. User interfaces may include, but are not limited to aphysical keyboard or keypad, a touchpad, a speaker, a microphone, etc.Peripheral component interfaces may include, but are not limited to, anon-volatile memory port, a USB port, an audio jack, and a power supplyinterface.

As discussed above, computing system 105 may also include a transmitterand receiver or a transceiver (not shown). The transmitter may be anytype of hardware device that generates or otherwise produces radio wavesin order to communicate with one or more other devices. The transmittermay be coupled with an antenna (not shown) in order to transmit data toone or more other devices. The transmitter is configurable or operableto receive digital data from one or more components of computing system105 via IX 220, and convert the received digital data into an analogsignal for transmission over an air interface. The receiver may be anytype of hardware device that can receive and convert a signal from amodulated radio wave into usable information, such as digital data. Thereceiver may be coupled with the antenna (not shown) in order to captureradio waves. The receiver is configurable or operable to send digitaldata converted from a captured radio wave to one or more othercomponents of computing system 105 via IX 220. In embodiments where atransceiver (not shown) is included with computing system 105, thetransceiver may be a single component configured to provide thefunctionality of a transmitter and a receiver as discussed above.

TEE 115 may be one or more hardware devices and software modulesconfigured to carry out secure operations and/or control the storage anduse of personal and/or confidential data. In various embodiments, theTEE 115 may be a single integrated circuit (IC) containing a processingdevice, memory, an internal bus/IX, and/or an I/O interface. As shown byFIG. 2, the TEE 115 includes memory 350, processor circuitry 310, IX 320and 325, and secure I/O interface 340.

Memory 350 may be a same type of device or similar hardware device asmemory circuitry 250, such as RAM, ROM, a flash memory device, a SSD,and/or other like storage media capable of storing and recording data.However, according to various embodiments, the memory 350 may only beaccessed (i.e., read and/or written to) by processor circuitry 310. Insuch embodiments, components that are external to trusted executionenvironment may access the memory 350 via secure I/O interface 340.Memory 350 is configurable or operable to program code for one or moresoftware components, such as vPOS 120, PCDB 125, and/or one or moreother like applications. The program code and/or software components maybe loaded into memory 350 from a separate computer readable storagemedium, from memory circuitry 250, using a drive mechanism (not shown),NIC 230, and/or I/O interface circuitry 240 via the secure I/O interface340.

The vPOS 120 may be a collection of software elements, engines, modules,applet(s), and/or program code that enables the computing system 105 toprocess POS transactions by validating and/or encrypting/decrypting POStransaction data, and/or otherwise operate according to the variousexample embodiments as disclosed herein. The vPOS 120 may be a nativeapplication, an applet (e.g., Java® applet), or a firmware application.PCDB 125 may be one or more databases that stores payment credentials inassociation with other payment credential-related information. Asdiscussed elsewhere, the PCDB 125 may be one or more relationaldatabases, one or more object databases, one or more column-orienteddatabases, one or more correlation databases, and/or the like.

IX 320 may be a same type of device or similar to IX 220 and/or IX 225and/or other suitable IX/bus technology for transferring data betweencomponents within TEE 115 and with components outside of TEE 115. Invarious embodiments, the processor circuitry 310 may be the same orsimilar as processor circuitry 210.

Processor circuitry 310 is configurable or operable to carry outinstructions of a computer program (e.g., vPOS 120) by performing thebasic arithmetical, logical, and input/output operations. The processorcircuitry 310 may include a single-core processor, a dual-coreprocessor, a triple-core processor, a quad-core processor, one or moredigital signal processor (DSP), an application-specific integratedcircuit (ASIC) device, and/or the like. The processor circuitry 310 mayperform a variety of functions for the computing system 105 and mayprocess data by executing program code, one or more software modules,firmware, middleware, microcode, hardware description languages, and/orany other like set of instructions stored in the memory 350. The programcode may be provided to processor circuitry 310 by memory 350 via bus320, and/or by processor circuitry 210 via secure I/O interface 340. Inorder to perform the variety of functions and data processingoperations, the program code and/or software components may be executedby the processor circuitry 310. On execution by the processor circuitry310, the processor circuitry 310 may cause computing system 105 toperform the various operations and functions delineated by the programcode.

For example, in various embodiments, the vPOS 120 may include variousmodules and/or program code configured to operate (using hardware and/orsoftware components) to process POS transactions and communicate variousPOS transaction-related data with the cloud POS service 135 via the ePOSclient 110 as described herein. Once the various modules and/or programcode of the vPOS 120 are loaded into memory 350 and executed by theprocessor circuitry 310, the processor circuitry 310 is configurable oroperable to cause computing system 105 to obtain payment credentialsand/or other like information from the PCDB 125; validate merchantterminals associated with a POS transaction by decrypting, deciphering,or otherwise decode merchant certificates; process POS transactionsusing the selected payment credentials; generate and encrypt paymentdata; and/or perform various other functions or combinations offunctions as disclosed herein. While specific modules are describedherein, it should be recognized that, in various embodiments, variousmodules may be combined, separated into separate modules, and/oromitted. Additionally, in various embodiments, one or more modules maybe implemented on separate devices, in separate locations, ordistributed, individually or in sets, across multiple processors,devices, locations, and/or in cloud-computing implementations.

In various embodiments, the TEE 115 may be a graphics and memorycontroller hub and the processor circuitry 310 and memory 350 may bepart of microcontroller IC that includes the Management Engine firmwareprovided by Intel®. In some embodiments, the TEE 115 may be a TrustedPlatform Module (TPM) provided by Intel® that operates in accordancewith ISO/IEC 11889:2009, wherein the processor circuitry 310 is a securecryptoprocessor. However, it should be noted that the TEE 115 may be anysecure region of a computing device that may protect data that is storedand/or processed within the TEE 115.

In some embodiments, computing system 105 may include many morecomponents than those shown in FIG. 2, such as a display device (e.g., acomputer monitor, a touchscreen, etc.), one or more input devices (e.g.,a physical keyboard, a touch screen, etc.), one or more image sensors, atransmitter/receiver (or alternatively, a transceiver), a mobile videocard and/or graphics processing unit (GPU), and other like components.

FIG. 3 illustrates the components of the computing system 105, inaccordance with other various example embodiments. As shown by FIG. 3,computing system 105 may include similar components as shown by FIG. 2,such as processor circuitry 210, bus 220, NIC 230, input/output (I/O)interface circuitry 240, and memory circuitry 250, each of which mayoperate in a same or similar manner as discussed with regard to FIG. 2.However, according to the example embodiment shown by FIG. 3, the TEE115 may be within memory circuitry 250. In some embodiments, computingsystem 105 may include many more components than those shown in FIG. 3,such as a display device (e.g., a computer monitor, a touchscreen,etc.), one or more input devices (e.g., a physical keyboard, a touchscreen, etc.), one or more image sensors, a transmitter/receiver (oralternatively, a transceiver), a mobile video card and/or graphicsprocessing unit (GPU), and other like components.

According to the example embodiment shown by FIG. 3, the TEE 115 may bea hardware enforceable container called an enclave, a secure enclave,and the like. The enclaves may be used to store security critical codeand/or data, such as payment credentials and/or other POS transactiondata. The enclaves may be one or more isolated regions of memorycircuitry 250 that are encrypted within the memory circuitry 250. Insome embodiments, the enclaves may be managed by a virtual machinemonitor (WM) of a virtual machine running as a guest operating system.The memory location of the enclaves may be protected from access by allhardware components and/or software components of computing system 105,regardless of a privilege level assigned to the hardware componentsand/or software components. In such embodiments, only the processorcircuitry 210 executing a secure application (e.g., ePOS client 110) mayaccess an enclave. In such embodiments, the operating system 260 mayinclude a secure driver that provides an interface for hardware devicesand/or software components to create secure applications; accessenclaves created by the secure applications; create secure applicationcertificates (e.g., an “application cryptogram” or “transactioncertificate”) that allow one or more software components; hardwaredevices; or external computing devices to attest to validate theiridentity; create secure channels between multiple enclaves; and/or otherlike secure operations. In embodiments where the processor circuitry 210is a multi-core processor, the processor circuitry 210 may executeprogram code from an enclave in parallel with unsecured program code. Invarious embodiments, the TEE 115 may be one or more secure enclavesdefined using the Intel® Software Guard Extensions (Intel® SGX).

FIG. 4 shows an arrangement 400 in which a POS transaction may beprocessed using the vPOS of the present disclosure, in accordance withvarious other example embodiments. As shown in FIG. 4, arrangement 400may include computing system 105A, merchant domain 130, paymentacquiring service 145, messaging service 160, network 150, and cloudtrusted execution environment 415. Additionally, computing system 105Amay include ePOS client 110, and the cloud trusted execution environment415 may include the vPOS 120 and PCDB 125. Furthermore, the merchantdomain may include a cloud POS service 135 and the merchant server 140(also referred to as “merchant 140”).

The cloud POS service 135, the merchant server 140, payment acquiringservice 145, messaging service 160, and the network 150 as shown in FIG.4 may be the same or similar to the cloud POS service 135, the merchantserver 140, payment acquiring service 145, messaging service 160, andthe network 150 as shown in FIG. 1. Additionally, the ePOS client 110,the vPOS 120, and the PCDB 125 of arrangement 400 may operate in a sameor similar fashion as the ePOS client 110, the vPOS 120, and the PCDB125 of arrangement 100. In contrast to computing system 105 of FIG. 1,as shown in FIG. 4, the computing system 105A does not include a TEE115, but instead, the TEE 115 is replaced with the cloud TEE 415.

The cloud TEE 415 may be one or more hardware computing devices that mayinclude one or more servers or other like network elements for providingone or more services. The one or more services provided by the cloudtrusted execution environment 415 may include processing POStransactions on behalf of the computing system 105. In this regard,cloud trusted execution environment 415 may communicate data (i.e.,transmit and receive) with ePOS client 110 located in the computingdevice 105A via network 150. In order to communicate with the ePOSclient 110, the cloud trusted execution environment 415 may generate POStransaction messages (which may be communicated to the ePOS client 110)in accordance with ISO 8583 and/or any other like standards forencrypting and/or encapsulating data for exchanging electronictransactions made by cardholders using payment cards. In suchembodiments, the ePOS client 110 of the computing system 105A may alsocommunicate with the cloud trusted execution environment 415 via network150. The communications between the computing system 105A and cloudtrusted execution environment 415 may be carried out in a same orsimilar fashion as the communications between the ePOS client 110 andthe vPOS 120 as discussed previously with regard to FIGS. 1-3. However,in the arrangement 400 the communications between the ePOS client 110and the vPOS 120 may additionally include encrypting and/or encipheringthe POS transaction messages according to one or more encryption orenciphering algorithms discussed herein prior to communicating suchmessages over the network connections 150.

In cloud-based embodiments, the ePOS applet(s) 121 may be web-basedwidgets or web-based applets that run in a browser, or within a nativeor hybrid application, operated by the computing system 105. In theseembodiments, the POS cloud 135 or some other cloud service also hosts orotherwise stores user credentials on behalf of the user in a same orsimilar manner as discussed with respect to the PCDB 125. Forcloud-hosted credentials, the systems that are granted credential accessestablish and maintain a strong pairing relationship with the cloud POSservice 135 (e.g., a secure session or the like). In one exampleimplementation, a time-based OTP (TOTP) cryptographic method may be usedfor this purpose.

FIG. 5 illustrates the components of example computing system 105A andcloud trusted execution environment 415 with the vPOS 120, in accordancewith various example embodiments. As shown, computing system 105A mayinclude processor circuitry 210, bus 220, NIC 230, input/output (I/O)interface circuitry 240, and memory circuitry 250. As shown, cloudtrusted execution environment 415 may include a processor 510, a networkinterface 530, and the TEE 115. The trusted execution environment mayinclude memory 350 and processor circuitry 310. In some embodiments,computing system 105A and/or cloud trusted execution environment 415 mayinclude many more components than those shown in FIG. 5, such as adisplay device (e.g., a computer monitor, a touchscreen, etc.), one ormore input devices (e.g., a physical keyboard, a touch screen, etc.),one or more image sensors, a transmitter/receiver (or alternatively, atransceiver), a mobile video card and/or graphics processing unit (GPU),and other like components.

The processor circuitry 210, the bus 220, the NIC 230, the I/O interfacecircuitry 240, and the memory circuitry 250 of the computing system 105Amay be the same or similar as the processor circuitry 210, the bus 220,the NIC 230, the I/O interface circuitry 240, and the memory circuitry250 of the computing device 10 discussed previously with regard to FIGS.2-3. Additionally, the TEE 115, the memory 350, the processor circuitry310, the bus 320 and the secure I/O interface 340 of the cloud trustedexecution environment 415 may be the same or similar to the TEE 115, thememory 350, the processor circuitry 310, the bus 320 and the secure I/Ointerface 340 of computing system 105 as discussed previously withregard to FIG. 2. Furthermore, the processor 510 may be a same orsimilar device that operates in a same or similar fashion as theprocessor circuitry 210, and the network interface 530 may be a same orsimilar device that operates in a same or similar fashion as the NIC230.

In contrast to computing system 105 discussed with regard to FIGS. 1-3,as shown in FIG. 5, the ePOS client 110 of computing system 105A mayaccess the vPOS 120 via the network 150 using the NIC 230 to communicatePOS transaction messages to the cloud trusted execution environment 415.The network interface 530 may receive the communicated POS transactionmessages and provide the POS transaction messages in their encryptedform to the processor 510, which may then route the POS transactionmessages to the secure I/O interface 340 in a same or similar fashion asdiscussed previously with regard to FIG. 2. The cloud trusted executionenvironment 415 may also communicate POS transaction messages to thecomputing system 105A via the network 150 by using the network interface530.

Furthermore, although not shown, in various embodiments, the cloudtrusted execution environment 415 may have a component configurationthat is similar to the configuration shown by FIG. 3. In suchembodiments, computing system 105A may still include similar componentsas shown by FIGS. 2 and 5, such as processor circuitry 210, bus 220, NIC230, input/output (I/O) interface circuitry 240, and memory circuitry250, each of which may operate in a same or similar manner as discussedwith regard to FIG. 2. Additionally, in such embodiments, the TEE 115may be within a memory device of the cloud trusted execution environment415 (not shown) and may operate in a same or similar fashion asdiscussed with regard to FIG. 3, such as the TEE 115 of the cloudtrusted execution environment 415 including one or more secure enclavesdefined using the Intel® SGX.

FIG. 6 illustrates a method 400 for processing a POS transaction, inaccordance with various example embodiments. FIGS. 7-14 illustratevarious user interface stages, each of which corresponds to an operationof method 600 of FIG. 6 having a same numeral. In particular, each ofFIGS. 7-14 illustrate an example user interface that may be displayed ona display device of computing system 105 as each operation of method 600is performed using computing system 105. However, it should be notedthat the process 600 may be performed by computing system 105A, whereinthe example user interfaces may be displayed on a display device ofcomputing system 105A as each operation of method 600 is performed usingcomputing system 105A. While particular examples and orders ofoperations are illustrated in FIGS. 6-14, in various embodiments, theseoperations may be re-ordered, broken into additional operations,combined, and/or omitted altogether. Furthermore, the user interfacesillustrated by FIGS. 7-14 may be generated or otherwise formed invarious artistic representations without departing from the exampleembodiments disclosed herein.

Referring to FIG. 6, at operation 700 the computing system 105 mayprovide a selection of payment options for completing a POS transaction.Referring to FIG. 7, the computing system 105 may display a screen 505that includes three payment option buttons 710A-C. In variousembodiments, the screen 505 may be displayed during an ecommercecheckout process for purchasing products and/or services from an onlinestore or a merchant website (e.g., a website associated with merchant140). As shown by FIG. 7, the computing system 105 may be a mobiledevice including a touchscreen display device, wherein a user mayprovide an input to the computing system 105 by performing one or moregestures on the touchscreen display device using a finger, a stylus,etc. The payment option buttons 710A-C may be graphical control elementsthat may be used to provide a selection of one of a plurality of paymentoptions. In such embodiments, the user may press one of the paymentoption buttons 710A-C to select a desired payment option. When a user ofcomputing system 105 selects a desired payment option (e.g., paymentoption 1 710A), the computing system 105 may activate the ePOS client110 so that the user may access the vPOS 120 to complete the POStransaction.

Referring back to FIG. 6, at operation 800 the computing system 105 mayobtain a unique identifier associated with the computing system 105 andprovide the unique identifier to initiate the POS transaction. Referringto FIG. 8, when the ePOS client 110 is activated, the ePOS client 110may display a screen 605 that allows a user to enter or input a uniqueidentifier associated with the computing system 105. In embodimentswhere the computing system 105 includes a touchscreen display device,the screen 805 may include a keypad that may be overlaid on top of theePOS client 110 (not shown) so as to enable the user of the computingdevice to enter the unique identifier into the text box 810. Text box810 may be any type of graphical control element that enables a user ofthe computing system 105 to input text information to be used forinitiating a POS transaction. The send button 815 may be a graphicalcontrol element that may operate in a same or similar fashion as thepayment option buttons 710A-C, which may be used to submit the uniqueidentifier to the cloud POS service 135.

In the embodiment shown by FIG. 8, the unique identifier may be a phonenumber associated with the computing system 105. As shown, a user of thecomputing system 105 may input the phone number into text box 810, andwhen the user selects the send button 815, the ePOS client 110 mayprovide the phone number to the cloud POS service 135 to initiate thePOS transaction. It should be noted that in some embodiments, the uniqueidentifier may be an email address, a media access control (MAC)address, a domain name, an IP address, and/or any other like uniqueidentifier.

Referring back to FIG. 6, at operation 900, the ePOS client 110 of thecomputing system 105 may receive a transaction initiation from the cloudPOS service 135. Referring to FIG. 9, when the computing system 105receives the transaction initiation, the ePOS client 110 may displayscreen 905, which includes message 910 that indicates that the computingsystem 105 has received a POS transaction initiation. In embodimentswhere the unique identifier is a phone number associated with thecomputing system 105, the transaction initiation may be received via atext message. In such embodiments, the text message may be a shortmessage service (SMS) message, a multimedia messaging service (MMS)message, or any other type of message that based in cellular networktechnology. It should be noted that in embodiments where the uniqueidentifier is a MAC address or an IP address, the message 910 may be apush notification sent by a messaging service (e.g., messaging service160), a notification in response to a client pull communication, and/orthe like. In various embodiments, the message 910 may be a graphicalcontrol element that allows a user of the computing system 105 toinitiate processing the POS transaction indicated by the message 910.For example, when the user selects the message 910, the ePOS client 110may provide a user interface that allows the user to select one or morepayment credentials to be used for processing the POS transaction.

Referring back to FIG. 6, at operation 1000, the ePOS client 110 of thecomputing system 105 may provide a selection of a payment credential tobe used for processing the POS transaction. Referring to FIG. 10, theePOS client 110 may display screen 1005, which includes message 1010,payment credential buttons 1015A-C, cancel button 1020, and authorizebutton 1025.

In the embodiment shown by FIG. 10, the message 1010 may indicate a POStransaction amount (e.g., $54.50) and a merchant payee (e.g., merchant140). The message 1010 may also include a trademark, symbol, emblem, orother like identifying image associated with the merchant payee. In someembodiments the message 1010 may include the same or similar informationas message 910.

The payment credential buttons 1015A-C may be graphical control elementsthat may operate in a same or similar fashion as buttons 710A-C and 815.The payment credential buttons 1015A-C may allow a user of the computingsystem 105 to select a desired payment credential stored in the PCDB125. Each of the payment credentials represented by payment credentialbuttons 1015A-C may include payment information that may be accepted bya merchant payee. In most embodiments, each of the payment credentialsmay be associated with a physical credit card, a charge card, a debitcard, a prepaid card, a gift card, an automated teller machine (ATM)card, an EBT card, a stored-value card, a fleet card, an electroniccheck, digital currency wallet, and/or other like physical paymentcredentials. In such embodiments, each payment credential may includepayment information, such as card number, expiration date, cardverification code (CVC) code, digital currency public-private key pairs,cardholder name, billing address, security questions and answers, andthe like. In some embodiments, each payment credential may be associatedwith an electronic form of payment, without a physical counterpart, suchas an electronic script or any other type of substitute for legaltender. In such embodiments, the payment credentials may include thesame or similar information as discussed previously with regard tophysical payment cards. Additionally, each payment credential may alsoinclude additional information that is required or desired to complete aPOS transaction, such as authentication terms and/or transaction termsrequired by a payment credential, a merchant authentication challenge, acryptographic client certificate that is unique to a payment credential,and/or other like POS transaction-related data.

Furthermore, FIG. 10 shows three payment credential buttons 1015A-C,each of which is associated with a different payment credential.However, according to various embodiments, the number of paymentcredential buttons that are displayed in screen 805 may vary accordingto the number and types of payment credentials accepted by the merchant140 and/or the number and types of payment credentials that are storedin the PCDB 125. Therefore, many more (or fewer) payment credentials maybe displayed in screen 805. For example, the merchant 140 may onlyaccept payment credentials associated with payment credential buttons1015A-C even though the PCDB 125 stores many more payment credentials.By way of another example, the PCDB 125 may only include the paymentcredentials associated with payment credential buttons 1015A-C, eventhough the merchant 140 may accept many more payment credentials.Additionally, in some embodiments, the POS transaction initiation mayindicate a geographic location of the merchant 140, and the ePOS client110 may obtain payment credentials from within the PCDB 125 that may beaccepted within a jurisdiction or other like venue containing thegeographic location of the merchant 140. By way of example, the PCDB 125may include payment credentials that may be accepted in the UnitedStates and payment credentials that may be accepted in France, and ifthe merchant 140 is located within the United States, the paymentcredential buttons 1015A-C may be associated with payment credentialsthat are issued by issuing banks located within the United States orotherwise accepted by merchants located within the United States, eventhough the computing system 105 may be located within France. In variousembodiments, the POS transaction initiation may indicate the types ofpayment credentials accepted by the merchant 140, and the ePOS client110 may generate screen 1005 to include a number of payment credentialbuttons 1015 based on a query of the PCDB 125 using the informationcontained in the POS transaction initiation. In some embodiments, theePOS client 110 may submit the query to the vPOS 120, which may conductthe actual search through the PCDB 125, while in other embodiments theePOS client 110 may search through the payment credential DB module 110independent of the vPOS 120. For example, the ePOS client 110 may submitthe query through a secure I/O interface 340 (see e.g., the exampleembodiments described with regard to FIGS. 2 and 5) or may issue one ormore SGX commands to query the PCDB 125 (see e.g., the exampleembodiments described with regard to FIGS. 3 and 5).

Once the user of the computing system 105 selects one of the paymentcredentials to be used for processing the POS transaction, such bypressing the payment credential button 1015A to select paymentcredential 1, the user may then select the authorize button 1025 toinitiate the vPOS 120 to process the POS transaction using the selectedpayment credential 1, or the user of the computing system 105 may selectthe cancel button 1020 to cancel the POS transaction.

Referring back to FIG. 6, at operation 1100, the ePOS client 110 of thecomputing system 105 may provide a passcode to authorize use of theselected payment credential. Referring to FIG. 11, the screen 1105 mayinclude message 1110, keypad 1115, cancel button 1120, and authorizebutton 1125, which may operate in a same or similar manner as message1010, keypad 1015, cancel button 1020, and submit button 1025 of FIG.10, respectively. In various embodiments, each of the paymentcredentials 1015A-C may require a passcode, password, or other likestring of numerals or string of characters to authenticate or otherwiseprove an identity of the user of the computing system 105. As willbecome apparent later, the passcode used at operation 1100 may bedifferent than a personal identification number (PIN) used to authorizeuse of a payment credential. In some embodiments, the passcode may bespecific to each payment credential, while in other embodiments, thepasscode may be a same passcode used to access the computing system 105,such as from a lockscreen or login screen of the computing system 105.Accordingly, in various embodiments, the PCDB 125 may store a passcodein association with each payment credential.

The keypad 1115 may include a set of buttons or other like graphicalcontrol elements arranged in a block or pad that bear a digit, symbol,or character that enables the user of the computing system 105 to enterthe passcode. Each of the graphical control elements within the keypad915 may operate in a same or similar manner as discussed with regard tobuttons 710A-C, 815, 1015A-C, 1020, 1025, etc. As shown by FIG. 11, thecomputing system 105 may be a mobile device including a touchscreendisplay device, wherein the user may press one or more of the graphicalcontrol elements of the keypad 1115 using a finger or stylus to enter orinput a passcode. In some embodiments where the computing system 105includes a touchscreen display device, a gesture-based passcode may beused instead of using keypad 1115 to enter a numeric-based and/orcharacter-based passcode. In such embodiments, a user may be required toperform one or more touch-gestures in a predetermined sequence toauthenticate or otherwise prove an identity of the user. In embodimentswhere the computing system 105 does not include a touchscreen displaydevice, the passcode may be entered using a physical keyboard or usingmouse point-and-click actions. Once the user of the computing system 105inputs a passcode using the keypad 1115, the user may then select theauthorize button 1125 to submit the passcode to the vPOS 120 to continueprocessing the POS transaction using the selected one of the paymentcredentials 1015A-C. Additionally, the user of the computing system 105may select the cancel button 1120 to cancel the POS transaction. Invarious embodiments, the ePOS client 110 may be operate in conjunctionwith the Protected Transaction Display (PTD) provided by Intel®, suchthat the screen 1105 is generated by an application running within theTEE 115 or otherwise outside of the operating system 260. In suchembodiments, the PTD may provide a graphics overlay and randomly placedinput options (e.g., buttons of keypad 1115), which may protect theselected inputs from malware scraping and/or other like maliciousattempts to obtain payment credential-related information. Furthermore,it should be noted that in various embodiments, instead of requiring apasscode to be entered by a user of computing system 105, at operation1100, biometric information (e.g., user voice recognition, facialrecognition, eye scan, fingerprint, etc.) may be used as anauthenticating factor for proving an identity of the user of thecomputing system 105. In such embodiments, instead of providing thekeypad 1115, the computing system 105 may execute an application thatutilizes one or more biometric sensors, or other like sensors to obtainthe biometric information.

Referring back to FIG. 6, at operation 1200, the vPOS 120 of thecomputing system 105 may begin processing the POS transaction using theselected payment credential when the provided passcode matches apasscode associated with the payment credential. In various embodiments,the ePOS client 110 may provide the input passcode from operation 1100to the vPOS 120, wherein the vPOS 120 compares the input passcode with apasscode associated with the selected payment credential. If the inputpasscode matches the passcode associated with the selected paymentcredential, the vPOS 120 may provide the ePOS client 110 with variousPOS transaction-related data associated with the selected paymentcredential to be communicated with the cloud POS service 135. In suchembodiments, while the computing system 105 is communicating with thecloud POS service 135, the ePOS client 110 may display screen 1205 toindicate to a user of the computing system 105 that the POS transactionis being processed. Message 1210 may indicate one or more operationsthat the computing system 105 is undertaking to process the POStransaction. Accordingly, in various embodiments, the message 1210 maydisplay information based on the operations that the computing system105 is performing. As shown, the screen 1205 may include progress image1215, which may be a graphical control element used to visualize aprogression of one or more computer operations. In some embodiments, theprogress image 1215 may include a progress bar, a textual representationof the progress in a percent format, a throbber, and/or other like ananimated graphical control element that visualizes that one or morecomputer operations are being performed.

Referring back to FIG. 6, at operation module 1300, the ePOS client 110of the computing system 105 may provide a PIN to authorize use of theselected payment credential. Referring to FIG. 13, the screen 1305 mayinclude message 1310, keypad 1315, cancel button 1320, and submit button1325, which may operate in a same or similar manner as message 1010,keypad 1015, cancel button 1020, and submit button 1025 of FIG. 10,respectively. In various embodiments, the PIN may be a numeric passwordthat may be used to indicate whether the user of the computing system105 is authorized to use the selected payment credential. In variousembodiments, the PIN that is input at operation module 1300 may be usedto authenticate the user with the cloud POS service 135 and/or the vPOS120, whereas the passcode discussed with regard to operation 1000 may beused to access the payment credential located within the TEE 115. Itshould be noted that, in some embodiments, the requirement to enter aPIN may be dependent on the purchase price, merchant requirements and/orpayment credential requirements. For example, some payment credentialsor merchants may not require a user to enter a PIN when a purchase priceis under a threshold amount or when the purchase price is not above athreshold amount. Once the user of the computing system 105 inputs a PINusing the keypad 1315, the user may then select the authorize button1325 to submit the PIN to the cloud POS service 135 to continueprocessing the POS transaction using the selected payment credential.Additionally, the user of the computing system 105 may select the cancelbutton 1320 to cancel the POS transaction. Furthermore, in variousembodiments, after operation module 1100 the ePOS client 110 may displayscreen 1205 as shown by FIG. 12 to indicate to the user of the computingsystem 105 that the POS transaction is currently being processed.

In various embodiments, the ePOS client 110 may be operate inconjunction with the PTD provided by Intel®, such that the screen 1105is generated by an application running within the TEE 115 or otherwiseoutside of the operating system 260. In such embodiments, the PTD mayprovide a graphics overlay and randomly placed input options (e.g.,buttons of keypad 1115), which may protect the selected inputs frommalware scraping and/or other like malicious attempts to obtain paymentcredential-related information. Furthermore, it should be noted that invarious embodiments, instead of requiring a PIN to be entered by a userof computing system 105, at operation 1300, biometric information (e.g.,user voice recognition, facial recognition, eye scan, fingerprint, etc.)may be used as an authenticating factor for authorizing use of theselected payment credential. In such embodiments, instead of providingthe keypad 1315, the computing system 105 may execute an applicationthat utilizes one or more biometric sensors, or other like sensors toobtain the biometric information.

Referring back to FIG. 6, at operation 1400, the ePOS client 110 of thecomputing system 105 may receive acknowledgment of completion of the POStransaction. Referring to FIG. 14, the ePOS client 110 may displayscreen 1410, which includes message 1410 and image 1415. The message1410 and the image 1415 may indicate that the POS transaction wassuccessful (as shown), or may indicate that the POS transaction wasunsuccessful (not shown).

FIG. 15 is a flowchart illustrating an example process 1500 ofprocessing a POS transaction, in accordance with various embodiments.For illustrative purposes, the operations of process 1300 will bedescribed as being performed by the computing system 105 utilizing thevarious modules, as described with respect to FIGS. 1-14. However, itshould be noted that other similar devices, such as computing system105A as discussed with regard to FIGS. 4-5, may operate the process 1500as described below. While particular examples and orders of operationsare illustrated in FIG. 15, in various embodiments, these operations maybe re-ordered, broken into additional operations, combined, and/oromitted altogether.

Referring to FIG. 15, at operation 1505, the vPOS 120 may receive, viathe ePOS client 110, a transaction initiation from a cloud POS service135, messaging service 160, or other device within the merchant domain130. In various embodiments, the transaction initiation may be a SMSmessage, a MMS message, an email message (or a file attached orotherwise included in an email message), a push notification, an OTTmessage, and/or any other like message that may be received by thecomputing system 105 over a wired or wireless network connection.

At operation 1510, the vPOS 120 may receive a selection of a paymentcredential from the ePOS client 110. The selection of the paymentcredential may obtained by the ePOS client 110 in a same or similarfashion as discussed with regard to FIGS. 6 and 10. At operation 1515,the vPOS 120 may obtain authentication parameters associated with theselected payment credential from within the PCDB 125. According tovarious embodiments, the vPOS 120 may obtain the authenticationparameters by querying the PCDB 125 according to known database queryingmethods. At operation 1520, the vPOS 120 may provide, via the ePOSclient 110, authentication parameters associated with the selectedpayment credential to the cloud POS service 135 or other device withinthe merchant domain 130. In various embodiments, the authenticationparameters may be security measures, defined by the selected paymentcredential, required for authenticating entities and/or communicatingdata between entities.

At operation 1525, the vPOS 120 may receive from the cloud POS service135, via the ePOS client 110, a cryptographic merchant certificate basedon the authentication parameters. The cryptographic merchant certificatemay be an application cryptogram or a transaction cryptogram (e.g.,referred to herein as a “merchant cryptogram”). Additionally oralternatively, the cryptographic merchant certificate may be a publickey certificate, digital certificate, identity certificate, etc. that isunique to the merchant 140, which may be used to prove that the merchant140 owns or otherwise possesses a public key. The cryptographic merchantcertificate may include information indicating the identity of themerchant 140, such as an IP address and/or domain name of the merchant140, a serial number that is unique to the cryptographic merchantcertificate, a digital signature used to verify that the cryptographicmerchant certificate originated from the merchant 140, a signaturealgorithm used to create the digital signature, an issuer identifiersuch as an IP address and/or domain name, generation date, expirationdate, key-usage information, a public key, an algorithm used to hash thepublic key (also referred to as a “thumbprint algorithm”), a hashedpublic key (also referred to as a “thumbprint”), and/or any other likeinformation. In various embodiments, the cryptographic merchantcertificate may be generated and issued to the merchant 140 by acertificate authority in accordance with EMV standards 4.3 and/or otherlike standards. However, in various embodiments, the authenticationparameters may define one or more criteria required by the selectedpayment credential to verify the identity of the merchant 140. Thus, invarious embodiments, the cryptographic merchant certificate may bealtered to fulfill one or more of the authentication parameters, or mayinclude additional information required by the authentication parametersto validate the identity of the merchant 140.

At operation 1530, the vPOS 120 may validate the merchant 140 identityusing the cryptographic merchant certificate. The vPOS 120 may validatethe merchant identity according to known methods, such as by using apublic key contained in the cryptographic merchant certificate,obtaining a public key associated with the merchant 140 from acertificate authority (either directly or via the cloud POS service135), validating the public key signature from the cryptographicmerchant certificate with the public key retrieved from the certificateauthority, confirming the IP address and/or domain name of the merchant140 listing in the cryptographic merchant certificate, generating ashared symmetric key to be used to encrypt POS transaction data,encrypting the symmetric key with the public key, and sending theencrypted symmetric key and public key back to ensure that only thecloud POS service 135 can decrypt the encrypted symmetric key and publickey using a private key. In some embodiments, the vPOS 120 may validatea digital signature included with the cryptographic merchant certificateaccording to known methods, which may include obtaining a session key,obtaining a private key associated with the merchant 140, decrypting thesession key using the private key, obtaining an encrypted hash valueassociated with the merchant 140, obtaining a public key associated withthe merchant 140, decrypting the encrypted hash value using the publickey, comparing the decrypted hash value with the calculated hash value,and validating the identity of the merchant 140 if the decrypted hashvalue matches the calculated hash value. It should be noted that themerchant 140 identity may be validated using one or more other knownmethods in addition to, or alternative to the aforementioned methods.

At operation 1535, the vPOS 120 may generate transaction data uponproperly validating the merchant 140. In various embodiments, thetransaction data may include transaction terms required by the selectedpayment credential, a cryptographic client certificate, and anauthentication challenge. The cryptographic client certificate may be anapplication cryptogram or a transaction cryptogram (e.g., referred toherein as a “client cryptogram”). Additionally or alternatively, thetransaction terms may include authorization information required by theselected payment credential to authorize payment for the POStransaction. For example, authorization information may indicate whetherthe user of the computing system 105 is required to enter a PIN, and insome embodiments, the requirement to enter a PIN may be dependent on thepurchase price or other like criteria. For example, some paymentcredentials may not require a user to enter a PIN when a purchase priceis under a threshold amount or when the purchase price is not above athreshold amount.

At operation 1540, the vPOS 120 may provide, via the ePOS client 110,the transaction data to the cloud POS service 135. Prior to providingthe transaction data to the ePOS client 110, the vPOS 120 may encryptthe transaction data using an RSA encryption algorithm, a triple dataencryption algorithm (3DES), a secure hash algorithm (SHA), a formatpreserving encryption algorithm, elliptic curve cryptography, anAdvanced Encryption Standard (AES) algorithm, and/or according to anyother type of encryption method. In response to properly validating thecryptographic client certificate and decrypting the authenticationchallenge, the cloud POS service 135 may solicit a PIN from the ePOSclient 110. The cryptographic client certificate may be validated in asame or similar manner as discussed previously with regard to validatingthe merchant 140 identity using the cryptographic merchant certificate.

At operation 1545, the vPOS 120 may receive, via the ePOS client 110,updated transaction terms from the cloud POS server 135. In variousembodiments, the updated transaction terms may be a stricter version ofthe transaction terms required by the merchant 140 and/or the paymentacquiring service 145 and the transaction terms provided by the vPOS 120at operation 1540. In such embodiments, the updated transaction termsmay include transaction terms that are common to both the transactionterms required by the selected payment credential and the transactionterms required by the merchant 140 (or required by the payment acquiringservice 145), as well as any transaction terms that are required by theselected payment credential or the merchant 140/payment acquiringservice 145 that are not included in the transaction terms of the otherentity. For example, if the selected payment credential requires a userto enter a PIN for POS transactions that are more than $50, and themerchant 140 requires a user to enter a PIN for POS transactions thatare more than $25, then the updated transaction terms may require a userto enter a PIN for a POS transaction having a payment amount that ismore than $25. By way of another example, if the selected paymentcredential requires a user to enter a PIN and a cardholder birthdate forPOS transactions that are more than $50, and the merchant 140 onlyrequires a user to enter a PIN for POS transactions that are more than$50, then the updated transaction terms may require a user to enter aPIN and a cardholder birthdate for transaction that are more than $50.In various embodiments, the vPOS 120 may accept or deny the updatedtransaction terms, wherein the vPOS 120 may process the POS transactionaccording to the transaction terms delineated by the selected paymentcredential if the vPOS 120 denies the updated transaction terms, or thevPOS 120 may process the POS transaction using the updated transactionterms if the vPOS 120 accepts the updated transaction terms.

At operation 1550, the vPOS 120 may generate and encrypt payment data.In various embodiments, the payment data may be generated and encryptedin response to properly validating a PIN and/or other like securityinformation as required by the updated transaction terms. In variousembodiments, the payment data may include transaction settlementauthorization information (e.g., billing information such as paymentamount, currency type, account number, billing/payment address, shippingaddress, and/or other like cardholder data) a digital signatureassociated with the payment credential and/or the computing system 105,and/or other like information. Once generated, the payment data may beencrypted using an RSA encryption algorithm, a triple data encryptionalgorithm (3DES), a secure hash algorithm (SHA), a format preservingencryption algorithm, elliptic curve cryptography, an AdvancedEncryption Standard (AES) algorithm, and/or according to any other typeof encryption method. At operation 1555, the vPOS 120 may provide, viathe ePOS client 110, the encrypted payment data to the cloud POS service135. Once the vPOS 120 provides the encrypted payment data, thecomputing system 105 may proceed back to operation 1505 to receive, viathe ePOS client 110, a transaction initiation from the cloud POS service135.

FIG. 16 is a flowchart illustrating an example process 1400 ofprocessing a POS transaction, in accordance with various embodiments.For illustrative purposes, the operations of process 1600 will bedescribed as being performed by the various elements as described withrespect to FIGS. 1-3. However, it should be noted that other similardevices, such as the computing system 105A as described with regard toFIGS. 4-5, may operate the process 1600 as described below. Whileparticular examples and orders of operations are illustrated in FIG. 16,in various embodiments, these operations may be re-ordered, broken intoadditional operations, combined, and/or omitted altogether.

Referring to FIG. 16, at operation 1603, the ePOS client 110 maytransmit a payment initiation to the merchant 140. In variousembodiments, operation 1603 may be performed during an ecommercecheckout procedure on a website associated with the merchant 140. Inresponse to the payment initiation, at operation 1606, the merchant 140may transmit a payment request to the cloud POS service 135.

At operation 1609, the cloud POS service 135 may transmit paymentinformation to the messaging service 160. The payment information mayinclude client device identification information (e.g., MAC address ofthe computing system 105, IP address of the computing system 105, and/orany other type of identifier), merchant identification information(e.g., MAC address of the merchant 140, IP address of the merchant 140,and/or any other like identifier), a POS transaction amount (e.g., apurchase price), a currency type for the POS transaction,merchant-accepted payment credentials, and/or other like POStransaction-related data. At operation 1612, the messaging service 160may transmit the payment information notification to the ePOS client110.

At operation 1615, the ePOS client 110 may enumerate the paymentcredentials. In various embodiments, the ePOS client 110 may query thePCDB 125 via the vPOS 120 to obtain a list of one or more paymentcredentials stored in the PCDB 125 that match the merchant-acceptedpayment credentials contained in the payment information notification.

At operation 1618, the ePOS client 110 may receive a selection of theone or more enumerated payment credentials, and may provide theselection of the one or more enumerated payment credentials to the vPOS120. At operation 1621, the vPOS 120 may obtain one or moreauthentication parameters and/or other like information associated withthe selected payment credential from the PCDB 125. As discussedpreviously, the authentication parameters may be security measures,defined by the selected payment credential, that are required forauthenticating entities and/or communicating data between entities. Atoperation 1624, the vPOS 120 may provide authentication parameters tothe ePOS client 110, which in turn may transmit the authenticationparameters to the cloud POS service 135.

At operation 1627, the cloud POS service 135 may transmit merchantparameters and a merchant certificate to the ePOS client 110, which inturn may provide the merchant parameters and the merchant certificate tothe vPOS 120. The merchant parameters may be security measures, definedby the merchant 140 and/or the payment acquiring service 145, that arerequired for authenticating entities and/or communicating data betweenentities. In various embodiments, the stricter security requirementsbetween the authentication parameters and the merchant parameters may beused to authenticate entities, encrypt payment data, encode data packetscontaining the payment data, and/or the like.

At operation 1630, the vPOS 1430 may validate the merchant certificateand the merchant parameters. Upon properly validating the merchantcertificate and the merchant parameters, at operation 1633, the vPOS mayprovide transaction terms, an authentication challenge and acryptographic client certificate to the ePOS client 110, which in turnmay transmit the transaction terms, the authentication challenge and thecryptographic client certificate to the cloud POS server 135.

At operation 1636, the cloud POS service 135 may validate thecryptographic client certificate and decrypt the authenticationchallenge. Upon properly decrypting the authentication challenge andproperly validating the cryptographic client certificate, at operation1639, the cloud POS service 135 may transmit a PIN solicitation to theePOS client 110, and in response, the ePOS client 110 may transmit aninputted PIN to the cloud POS service 135. At operation 1642, the cloudPOS service 135 may generate a PIN block based on the PIN receivedduring the PIN solicitation. In various embodiments, the user may berequired to enter a PIN in order to authorize use of the selectedpayment credential for the POS transaction. The PIN may be issued to theuser by an issuer of the payment credential and may be used toauthenticate the user's identity. In typical POS transactions, thecardholder is usually required to enter their PIN into a standalonephysical POS terminal, the standalone physical POS terminal encodes thePIN into a PIN block and sends the PIN block to the merchant domain 130for payment processing. In typical POS transactions where the paymentcredential is a smart card that includes a EMV chip, the cardholder isusually required to enter their PIN into the standalone physical POSterminal, and the standalone physical POS terminal sends the PIN to theto the smart card to check if the PIN is correct, wherein the smart cardsends the result to the terminal so that the transaction continues ifthe PIN is correct. According to various example embodiments, when theuser of the computing system 105 enters a PIN, the PIN may be encodedinto a PIN block to protect the PIN during transmission between the ePOSclient 110 and the cloud POS service 135. In such embodiments, the PINmay be enciphered/deciphered and communicated according to ISO 9564, oneor more EMV standards, and/or any other like standard. According toother embodiments, the PCDB 125 may store a PIN associated with theselected payment credential, and when the user of the computing system105 enters a PIN, the entered PIN may be checked against the stored PIN.In some embodiments, the PIN may not be required to be enciphered whenshared between the ePOS client 110 and the vPOS 120, which may reducethe amount of computational resources used for processing the POStransaction. It should be noted that in other embodiments, other typesof authentication methods may be used instead of, or in addition tousing a PIN to authorize use payment credentials.

At operation 1645, the cloud POS service 135 may transmit the cipheredPIN and updated transaction terms to the ePOS client 110, which in turn,may provide the ciphered PIN and the updated transaction terms to thevPOS 120. At operation 1648, the vPOS 120 may verify the PIN anddigitally sign the updated transaction terms.

At operation 1651, the vPOS 120 may generate and encrypt payment data.In various embodiments, the payment data may be encrypted according toEMV standards. At operation 1654, the vPOS 120 may provide the encryptedpayment data to the POS UI, which in turn, may transmit the encryptedpayment data to the cloud vPOS 135, which in turn, may transmit theencrypted payment data to the acquirer 145. At operation 1657, theacquirer 145 may transmit a payment status message to the cloud POSservice 135. At operation 1660, the cloud POS service 135 may transmit apayment status message to the merchant 140. At operation 1663, themerchant 140 may transmit a payment confirmation to the ePOS client 110.

Some non-limiting Examples are provided below.

Example A01 includes a computer-implemented method for processing apoint of sale (POS) transaction. The method may comprise receiving, by avirtual POS terminal within a trusted execution environment of a cloudtrusted execution environment, a transaction initiation from a networkelement via a POS user interface (UI) module (or “POS client”) whereinthe transaction initiation indicates the POS transaction and one or morepayment options to be used for processing the POS transaction;receiving, by the virtual POS terminal from the ePOS client, a selectionof a payment credential matching one of the one or more payment options;obtaining, by the virtual POS terminal, the selected payment credentialfrom within a payment credential storage unit located in the trustedexecution environment; validating, by the virtual POS terminal, amerchant domain associated with the transaction initiation; encrypting,by the virtual POS terminal, payment data when the merchant domain isproperly validated; and providing, by the virtual POS terminal, theencrypted payment data to the ePOS client wherein the ePOS clientcommunicates the encrypted payment data to the network element.

Example A02 includes the method of the preceding example, and/oraccording to any example disclosed herein, wherein the paymentcredential storage unit stores a plurality of payment credentials andwherein obtaining the selected payment credential comprises obtainingone of the plurality of payment credentials.

Example A03 includes the method of any of the preceding examples, and/oraccording to any example disclosed herein, wherein the selected paymentcredential defines authentication parameters required to validate themerchant identity and process the POS transaction using the paymentcredential, and the method further comprises providing theauthentication parameters to the ePOS client, wherein the ePOS client isto provide the authentication parameters to the network element.

Example A04 includes the method of any of the preceding examples, and/oraccording to any example disclosed herein, further comprising receiving,via the ePOS client, a cryptographic merchant certificate wherein themerchant certificate is based on the authentication parameters, whereinthe validating comprises decrypting the cryptographic merchantcertificate; generating transaction data upon validation of the merchantdomain, wherein the transaction data includes a cryptographic clientcertificate, payment credential transaction terms defined by theauthentication parameters, and a merchant authentication challenge; andencrypting the transaction data.

Example A05 includes the method of any of the preceding examples, and/oraccording to any example disclosed herein, further comprising receiving,from the network element via the ePOS client, a PIN block; decipheringthe PIN block; and upon properly deciphering the PIN block, generatingthe payment data wherein the payment data includes a digital signatureassociated with the payment credential and a payment address associatedwith the payment credential.

Example A06 includes the method of any of the preceding examples, and/oraccording to any example disclosed herein, wherein the paymentcredential storage unit stores a plurality of passcodes in associationwith a corresponding one of a plurality of payment credentials, whereineach of the plurality of passcodes is to be entered to authorize use ofthe corresponding one of the plurality of payment credentials, and theselected payment credential is one of the plurality of paymentcredentials, and the method further comprises providing an indication tothe ePOS client to generate a UI for inputting passcodes; receiving aninput passcode from the ePOS client; determining whether the inputpasscode is equal to a passcode stored in association with the selectedpayment credential; and authorizing the selected payment credential tobe used for processing the POS transaction when the input passcode isdetermined to be equal to the passcode stored in association with theselected payment credential.

Example A07 includes the method of any of the preceding examples, and/oraccording to any example disclosed herein, wherein receiving atransaction initiation comprises receiving a transaction initiation thatincludes a purchase price of the POS transaction and a currency to beused to process the POS transaction.

Example A08 includes the method of any of the preceding examples, and/oraccording to any example disclosed herein, wherein the receiving of atransaction initiation, the receiving of a selection of a paymentcredential, the obtaining, the validating, the encrypting and theproviding are performed by the virtual POS terminal operating on asecure processor of the trusted execution environment, with the ePOSclient being an only interface communicatively coupled with the virtualPOS terminal.

Example A09 includes the method of any of the preceding examples, and/oraccording to any example disclosed herein, further comprising receiving,by the ePOS client, the transaction initiation via a text message or amessaging service message that includes a unique identifier of thecomputing device provided by a user of the computing device.

Example B01 includes a computing device first means to receive atransaction initiation, and provide a selection of a payment credentialto be used to process a POS transaction. The computing device comprisesa second means, communicatively coupled with the first means, to processthe POS transaction in response to the selection of the paymentcredential. The second means comprises a third means to store theselected payment credential; and a fourth means to validate a merchantassociated with the transaction initiation, process the POS transactionusing the selected payment credential to generate payment data, andencrypt the payment data. The first means is further to receive theencrypted payment data from the fourth means, and communicate theencrypted payment data to a network element.

Example B02 includes the computing device of the preceding example,and/or according to any example disclosed herein, wherein the firstmeans is to receive a transaction initiation that indicates one or morepayment options to be used for the POS transaction, and the selectedpayment credential is to match one of the one or more payment options.

Example B03 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thefirst means is to provide a selected payment credential that definesauthentication parameters required to validate the merchant identity andthe second means is to process the POS transaction using the paymentcredential, wherein the fourth means is to provide the authenticationparameters to the first means, and the first means is to provide theauthentication parameters to the network element.

Example B04 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thefirst means is to receive a cryptographic merchant certificate whereinthe merchant certificate is based on the authentication parameters, andthe fourth means is to decrypt the cryptographic merchant certificate tovalidate the merchant, and upon validation of the merchant, the fourthmeans is to generate and encrypt transaction data, wherein thetransaction data includes a cryptographic client certificate, paymentcredential transaction terms defined by the authentication parameters,and a merchant authentication challenge.

Example B05 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thefirst means is to receive a personal identification number, PIN,solicitation upon proper decryption of the cryptographic clientcertificate by the network element, and upon proper decryption of themerchant authentication challenge, and in response to PIN solicitation,the first means is to provide a UI to input a PIN, and communicate theinput PIN to the network element, wherein the first means is to receivea PIN block and updated transaction terms upon validation of the inputPIN.

Example B06 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thefirst means is to receive updated transaction terms that are based on acombination of the payment credential transaction terms and merchantrequired transaction terms, and provide the updated transaction terms tothe fourth means, and the fourth means is to accept or deny the updatedtransaction terms, process the POS transaction according to the paymentcredential transaction terms when the fourth means denies the updatedtransaction terms, and process the POS transaction according to theupdated transaction terms when the fourth means accepts the updatedtransaction terms.

Example B07 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thefirst means is to receive updated transaction terms that includetransaction terms which are common to both the payment credentialtransaction terms and merchant required transaction terms, and anytransaction terms that are required by one of the payment credentialtransaction terms or the merchant required transaction terms but notincluding the other one of the payment credential transaction terms orthe merchant required transaction terms, and provide the updatedtransaction terms to the fourth means, and the fourth means is toprocess the POS transaction according to the updated transaction terms.

Example B08 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thefirst means is to receive PIN block that is enciphered using one offormat 0, format 1, format 2, or format 3 in accordance withInternational Organization for Standardization (ISO) 9564.

Example B09 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thefourth means is to receive the PIN block from the first means, decipherthe PIN block, and upon a proper decipher of the PIN block, the fourthmeans is to generate the payment data wherein the payment data includesa digital signature associated with the payment credential and a paymentaddress associated with the payment credential.

Example B10 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thefirst means is to receive a payment confirmation from the merchant whenthe encrypted payment information is properly decrypted by a paymentacquiring service associated with the payment credential.

Example B11 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thethird means is to store a plurality of payment credentials, and thefirst means is to display a set of the plurality of payment credentialsbased on information contained in the transaction initiation.

Example B12 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thethird means is to store, in association with each of the plurality ofpayment credentials, information indicating one or more jurisdictions inwhich each of the plurality of payment credentials are accepted, and thefirst means is to display ones of the plurality of payment credentialsthat are accepted within a jurisdiction of the merchant based on ageographic location of the merchant, wherein the information containedin the transaction initiation includes information indicating thegeographic location of the merchant.

Example B13 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thethird means is to store a plurality of passcodes in association with acorresponding one of a plurality of payment credentials wherein theselected payment credential is one of the plurality of paymentcredentials, and the passcode stored in association with the selectedpayment credential is to be entered to authorize use of the selectedpayment credential, and wherein the first means is to provide a UI forinput of passcodes.

Example B14 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thefirst means is to receive a transaction initiation that includes apurchase price of the POS transaction and a currency to be used toprocess the POS transaction.

Example B15 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thesecond means comprises another processor, the fourth means is to operateon the other processor to process the POS transaction, and the firstmeans is an only module communicatively coupled with the fourth means.

Example B16 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thesecond means is one of Intel® Management Engine, Intel® Software GuardExtensions, or Intel® Converged Security Engine (CSE).

Example B17 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thefirst means is to receive the transaction initiation via a text messageor a messaging service message wherein a unique identifier of thecomputing device is provided by a user of the computing device toinitialize the transaction initiation.

Example B18 includes the computing device of any of the precedingexamples, and/or according to any example disclosed herein, wherein thetext message is one of a short message service (SMS) message, amultimedia messaging service (MMS) message, an Over-the-Top (OTT)message, a push notification, or an email message.

Example C01 includes a computing system comprising: applicationprocessor circuitry arranged to operate a point of sale (POS) client to:receive a transaction initiation, and provide a selection of a paymentcredential to be used to process a POS transaction; a trusted executionenvironment (TEE), the TEE communicatively coupled with the applicationprocessor circuitry, the TEE arranged to process the POS transaction inresponse to the selection of the payment credential, wherein the TEEcomprises: a payment credential storage unit arranged to store one ormore payment credentials including the selected payment credential; anda virtual POS terminal arranged to validate a merchant associated withthe transaction initiation, obtain the selected payment credential fromthe payment credential storage unit, process the POS transaction usingthe selected payment credential to generate payment data, and encryptthe payment data, wherein the POS client is arranged to receive theencrypted payment data from the virtual POS terminal; and networkinterface circuitry communicatively coupled with the applicationprocessor circuitry, the network interface circuitry arranged tocommunicate the encrypted payment data to a merchant system owned oroperated by the merchant.

Example C02 includes the computing system of example C01 and/or someother examples herein, wherein the transaction initiation indicates oneor more payment options to be used for the POS transaction, and theselected payment credential is to match one of the one or more paymentoptions.

Example C03 includes the computing system of examples C01-C02 and/orsome other examples herein, wherein the POS client is arranged toprovide a selected payment credential that defines authenticationparameters required to validate a merchant identity of the merchant andthe trusted execution environment is to process the POS transactionusing the payment credential, wherein the virtual POS terminal isarranged to provide the authentication parameters to the networkinterface circuitry via the POS client for transmission to the merchantsystem.

Example C04 includes the computing system of example C03 and/or someother examples herein, wherein: the POS client is arranged to receive,via the network interface circuitry and the POS client, a cryptographicmerchant certificate that is based on the authentication parameters, andthe virtual POS terminal is arranged to decrypt the cryptographicmerchant certificate to validate the merchant identity, and uponvalidation of the merchant identity, the virtual POS terminal isarranged to generate and encrypt transaction data, wherein thetransaction data includes a cryptographic client certificate, paymentcredential transaction terms defined by the authentication parameters,and a merchant authentication challenge.

Example C05 includes the computing system of example C04 and/or someother examples herein, wherein the POS client is arranged to: receive,via the network interface circuitry and the POS client, a personalidentification number (PIN) solicitation upon proper decryption of thecryptographic client certificate by the merchant system; and upon properdecryption of the merchant authentication challenge and in response toPIN solicitation, the POS client is arranged to: cause a UI to input aPIN to be generated and displayed; and provide the input PIN to thenetwork interface circuitry via the POS client for transmission to themerchant system, wherein the POS client is arranged to receive, from themerchant system via the network interface circuitry, a PIN block andupdated transaction terms upon validation of the input PIN.

Example C06 includes the computing system of example C05 and/or someother examples herein, wherein the updated transaction terms are basedon a combination of the payment credential transaction terms andmerchant required transaction terms, and wherein: the POS client isarranged to provide the updated transaction terms to the virtual POSterminal, and the virtual POS terminal is arranged to accept or deny theupdated transaction terms, process the POS transaction according to thepayment credential transaction terms when the virtual POS terminaldenies the updated transaction terms, and process the POS transactionaccording to the updated transaction terms when the virtual POS terminalaccepts the updated transaction terms.

Example C07 includes the computing system of examples C05-C06 and/orsome other examples herein, wherein the updated transaction termsinclude transaction terms which are common to both the paymentcredential transaction terms and merchant required transaction terms,wherein any transaction terms are required by one of the paymentcredential transaction terms or the merchant required transaction termsbut not included in the other one of the payment credential transactionterms or the merchant required transaction terms, and wherein: the POSclient is arranged to provide the updated transaction terms to thevirtual POS terminal, and the virtual POS terminal is arranged toprocess the POS transaction according to the updated transaction terms.

Example C08 includes the computing system of examples C05-C07 and/orsome other examples herein, wherein the virtual POS terminal is arrangedto receive the PIN block from the POS client, decipher the PIN block,and upon a proper decipher of the PIN block, the virtual POS terminal isarranged to generate the payment data wherein the payment data includesa digital signature associated with the payment credential and a paymentaddress associated with the payment credential.

Example C09 includes the computing system of example C08 and/or someother examples herein, wherein the POS client is arranged to receive apayment confirmation from the merchant system via the network interfacecircuitry when the encrypted payment information is properly decryptedby a payment acquiring service associated with the payment credential.

Example C10 includes the computing system of examples C01-C09 and/orsome other examples herein, wherein the payment credential storage unitis arranged to store a plurality of payment credentials, and the POSclient is arranged to cause display of a set of the plurality of paymentcredentials based on information contained in the transactioninitiation.

Example C11 includes the computing system of examples C01-C10 and/orsome other examples herein, wherein the payment credential storage unitis arranged to store a plurality of passcodes in association with acorresponding one of a plurality of payment credentials wherein theselected payment credential is one of the plurality of paymentcredentials, and the passcode stored in association with the selectedpayment credential is to be entered to authorize use of the selectedpayment credential, and wherein the POS client is arranged to cause a UIfor input of passcodes to be displayed.

Example C12 includes the computing system of examples C01-C11 and/orsome other examples herein, wherein the transaction initiation includesa purchase price of the POS transaction and a currency to be used toprocess the POS transaction.

Example C13 includes the computing system of examples C01-C12 and/orsome other examples herein, wherein the TEE is a tamper-resistantchipset including a secure processor, and the virtual POS terminal isarranged to operate on the secure processor to process the POStransaction, and the POS client is an only module outside of the TEEcommunicatively coupled with the virtual POS terminal.

Example C14 includes the computing system of examples C01-C12 and/orsome other examples herein, wherein the TEE is one of Intel® ManagementEngine, Intel® Software Guard Extensions, or Intel® Converged SecurityEngine (CSE).

Example C15 includes the computing system of examples C01-C14 and/orsome other examples herein, wherein the network interface circuitry isarranged to receive the transaction initiation via a text message or amessaging service message, wherein a unique identifier of the computingsystem is provided by a user of the computing system to initialize thetransaction initiation.

Example C16 includes the computing system of example C15 and/or someother examples herein, wherein the text message is a short messageservice (SMS) message, a multimedia messaging service (MMS) message, anOver-the-Top (OTT) message, a push notification, or an email message.

Example D01 includes a virtual point of sale (POS) method for processinga POS transaction, the method comprising: receiving a transactioninitiation from a merchant system via network interface circuitry of acomputing system that includes the computing device and a POS userinterface (UI) module operated by an application processor of thecomputing system, wherein the transaction initiation indicates the POStransaction and one or more payment options to be used for processingthe POS transaction; receiving, from the POS client, a selection of apayment credential matching one of the one or more payment options;obtaining the selected payment credential from within a paymentcredential storage unit located in a trusted execution environment(TEE); validating a merchant domain associated with the transactioninitiation, the merchant domain including the merchant system;encrypting payment data when the merchant domain is properly validated;and providing the encrypted payment data to the network interfacecircuitry via the POS client for communication of the encrypted paymentdata to the merchant system.

Example D02 includes the method of example D01 and/or some otherexamples herein, wherein the payment credential storage unit stores aplurality of payment credentials, and wherein obtaining the selectedpayment credential comprises: obtaining one of the plurality of paymentcredentials from the payment credential storage unit.

Example D03 includes the method of examples D01-D02 and/or some otherexamples herein, wherein the selected payment credential definesauthentication parameters required to validate a merchant identity ofthe merchant domain and process the POS transaction using the paymentcredential, and the method comprises: providing the authenticationparameters to the network interface circuitry via the POS client fortransmission to the merchant system.

Example D04 includes the method of example D03 and/or some otherexamples herein, further comprising: receiving, from the merchant systemvia the network interface circuitry and the POS client, a cryptographicmerchant certificate wherein the merchant certificate is based on theauthentication parameters, wherein validating the merchant domaincomprises: decrypting the cryptographic merchant certificate, generatingtransaction data upon validation of the merchant domain, wherein thetransaction data includes a cryptographic client certificate, paymentcredential transaction terms defined by the authentication parameters,and a merchant authentication challenge, and encrypting the transactiondata.

Examples D05 includes the method of example D04 and/or some otherexamples herein, further comprising: receiving, from the merchant systemvia the network interface circuitry and the POS client, a PIN block;deciphering the PIN block; and generating, upon proper decipher of thePIN block, the payment data wherein the payment data includes a digitalsignature associated with the payment credential and a payment addressassociated with the payment credential.

Examples D06 includes the method of examples D01-D05 and/or some otherexamples herein, wherein the payment credential storage unit stores aplurality of passcodes in association with a corresponding one of aplurality of payment credentials, wherein each of the plurality ofpasscodes is to be entered to authorize use of the corresponding one ofthe plurality of payment credentials, and the selected paymentcredential is one of the plurality of payment credentials, and themethod comprises: providing an indication to the POS client to generateand display a UI for inputting passcodes; receiving an input passcodefrom the POS client; determining whether the input passcode is equal toa passcode stored in association with the selected payment credential;and authorizing the selected payment credential to be used forprocessing the POS transaction when the input passcode is determined tobe equal to the passcode stored in association with the selected paymentcredential.

Example D07 includes the method of examples D01-D06 and/or some otherexamples herein, wherein the transaction initiation includes a purchaseprice of the POS transaction and a currency to be used to process thePOS transaction.

Example D08 includes the method of examples A17-D07 and/or some otherexamples herein, wherein the computing device is a secure processor ofthe TEE, and wherein the POS client is to be operated by a host platformof a computing system including the secure processor, and the POS clientis an only interface outside of the TEE that is communicatively coupledwith the virtual POS terminal.

Example D09 includes the method of examples D01-D08 and/or some otherexamples herein, wherein the transaction initiation is a text message ora messaging service message that includes a unique identifier of thecomputing device provided by a user of the computing device.

Example Z01 may include an apparatus comprising means to perform one ormore elements of a method described in or related to any of examplesA01-A09, B01-B18, C01-C16, D01-D09, or any other method or processdescribed herein. Example Z02 may include one or more non-transitorycomputer-readable media comprising instructions to cause an electronicdevice, upon execution of the instructions by one or more processors ofthe electronic device, to perform one or more elements of a methoddescribed in or related to any of examples A01-A09, B01-B18, C01-C16,D01-D09, or any other method or process described herein. Example Z03may include an apparatus comprising logic, modules, or circuitry toperform one or more elements of a method described in or related to anyof examples A01-A09, B01-B18, C01-C16, D01-D09, or any other method orprocess described herein. Example Z04 may include a method, technique,or process as described in or related to any of examples A01-A09,B01-B18, C01-C16, D01-D09, or portions or parts thereof. Example Z05 mayinclude an apparatus comprising: one or more processors and one or morecomputer-readable media comprising instructions that, when executed bythe one or more processors, cause the one or more processors to performthe method, techniques, or process as described in or related to any ofexamples A01-A09, B01-B18, C01-C16, D01-D09, or portions thereof.Example Z06 may include a signal as described in or related to any ofexamples A01-A09, B01-B18, C01-C16, D01-D09, or portions or partsthereof. Example Z07 may include a datagram, packet, frame, segment,protocol data unit (PDU), or message as described in or related to anyof examples A01-A09, B01-B18, C01-C16, D01-D09, or portions or partsthereof, or otherwise described in the present disclosure. Example Z08may include a signal encoded with data as described in or related to anyof examples A01-A09, B01-B18, C01-C16, D01-D09, or portions or partsthereof, or otherwise described in the present disclosure. Example Z09may include a signal encoded with a datagram, packet, frame, segment,protocol data unit (PDU), or message as described in or related to anyof examples A01-A09, B01-B18, C01-C16, D01-D09, or portions or partsthereof, or otherwise described in the present disclosure. Example Z10may include an electromagnetic signal carrying computer-readableinstructions, wherein execution of the computer-readable instructions byone or more processors is to cause the one or more processors to performthe method, techniques, or process as described in or related to any ofexamples A01-A09, B01-B18, C01-C16, D01-D09, or portions thereof.Example Z11 may include a computer program comprising instructions,wherein execution of the program by a processing element is to cause theprocessing element to carry out the method, techniques, or process asdescribed in or related to any of examples A01-A09, B01-B18, C01-C16,D01-D09, or portions thereof.

Although certain embodiments have been illustrated and described hereinfor purposes of description, a wide variety of alternate and/orequivalent embodiments or implementations calculated to achieve the samepurposes may be substituted for the embodiments shown and describedwithout departing from the scope of the present disclosure. Thisapplication is intended to cover any adaptations or variations of theembodiments discussed herein, limited only by the claims.

1-25. (canceled)
 26. A mobile computing system comprising: a richexecution environment (REE) to communicatively couple with a trustedexecution environment (TEE) during operation of the mobile computingsystem, the TEE and the REE are to operate in isolation from oneanother; the REE is arranged to operate a point of sale (POS) client,the POS client is to provide a user input to a virtual POS terminal(vPOS) operating within the TEE; and the TEE is arranged to operate thevPOS to: authenticate a user of the mobile computing system based on theuser input, process a transaction while a trusted state with a cloud POSservice is maintained, and prevent access to the vPOS when the trustedstate with the cloud POS service is not maintained.
 27. The computingsystem of claim 26, wherein maintenance of the trusted state with thecloud POS service takes place over a network connection between the vPOSand the cloud POS service.
 28. The computing system of claim 26, whereinthe TEE further includes a cloud POS service security domain (SD), andmaintenance of the trusted state with the cloud POS service takes placebetween the vPOS and the cloud POS service SD.
 29. The computing systemof claim 26, wherein, to prevent access to the vPOS, the vPOS is totransition from an active state to an inactive state.
 30. The computingsystem of claim 26, wherein the POS client is to: receive a transactioninitiation, the transaction initiation indicates one or more paymentoptions to be used for the transaction; receive another user inputindicating a selected payment credential from among the one of the oneor more payment options; provide an indication of the selected paymentcredential to the vPOS.
 31. The computing system of claim 30, whereinthe selected payment credential defines authentication parametersrequired to validate an identity of a party to the transaction, and thevPOS is to: provide the authentication parameters for transmission toanother computing system operated by the party to the transaction;receive a first cryptographic certificate based on the authenticationparameters from the other computing system; decrypt the firstcryptographic certificate to validate the identity of the party to thetransaction, and upon validation of the identity, generate and encrypttransaction data, the transaction data including a second cryptographiccertificate, payment credential transaction terms defined by theauthentication parameters, and an authentication challenge.
 32. Thecomputing system of claim 31, wherein the POS client is to: receive anauthentication solicitation upon proper decryption of the secondcryptographic certificate by the other computing system; and afterproper decryption of the authentication challenge and in response toauthentication solicitation, generate and render a user interface toobtain the user input to authenticate the user.
 33. The computing systemof claim 32, wherein the vPOS is to: receive, from the other computingsystem, updated transaction terms upon validation of the user, theupdated transaction terms being based on a combination of the paymentcredential transaction terms and transaction terms of the othercomputing system; process the transaction according to the paymentcredential transaction terms when the vPOS denies the updatedtransaction terms; and process the transaction according to the updatedtransaction terms when the vPOS accepts the updated transaction terms.34. The computing system of claim 33, wherein the vPOS is to: receive apersonal identification number (PIN) block from the other computingsystem; and upon a proper decipher of the PIN block, generate paymentdata to include a digital signature associated with the paymentcredential.
 35. The computing system of claim 29, wherein thetransaction initiation includes a transaction amount of the POStransaction and a currency value to be used to process the POStransaction.
 36. One or more non-transitory computer-readable media(NTCRM) comprising instructions for a virtual point of sale terminal(vPOS), wherein execution of the instructions by a trusted executionenvironment (TEE) is to cause the TEE to: obtain a user input from apoint of sale (POS) client that is to operate within a rich executionenvironment (REE), the REE is to operate in isolation from the TEE;authenticate a user of a mobile computing system based on the userinput; process a transaction while a trusted state with a cloud POSservice is maintained; and prevent access to the vPOS when the trustedstate with the cloud POS service is not maintained.
 37. The one or moreNTCRM of claim 36, wherein the TEE further includes a cloud POS servicesecurity domain (SD), and maintenance of the trusted state with thecloud POS service takes place between the vPOS and the cloud POS serviceSD via a network connection between the vPOS and the cloud POS service.38. The one or more NTCRM of claim 36, wherein the REE and the TEE areimplemented in a same mobile computing system.
 39. The one or more NTCRMof claim 36, wherein the REE is implemented in a mobile computing systemand the TEE is implemented by one or more compute nodes of a cloudcomputing service.
 40. The one or more NTCRM of claim 36, whereinexecution of the instructions is to cause the TEE to: receive anindication of a selected payment credential from the POS client, whereinthe selected payment credential defines authentication parametersrequired to validate an identity of a party to the transaction; send theauthentication parameters to a computing system operated by the party tothe transaction; receive a first cryptographic certificate based on theauthentication parameters from the computing system operated by theparty to the transaction; decrypt the first cryptographic certificate tovalidate the identity of the party to the transaction; upon validationof the identity of the party to the transaction, generate and encrypttransaction data, the transaction data including a second cryptographiccertificate, payment credential transaction terms defined by theauthentication parameters, and an authentication challenge; receive,from the computing system operated by the party to the transaction,updated transaction terms upon validation of the user, the updatedtransaction terms being based on a combination of the payment credentialtransaction terms and transaction terms of the other computing system;process the transaction according to the payment credential transactionterms when the vPOS denies the updated transaction terms; and processthe transaction according to the updated transaction terms when the vPOSaccepts the updated transaction terms.
 41. A method of operating a pointof sale terminal (POS) client, the POS client is to operate within arich execution environment (REE) of a mobile computing system, the REEbeing isolated from a trusted execution environment (TEE), the methodcomprising: receiving a transaction initiation from a remote computingsystem; generating and rendering a graphical user interface (GUI) inresponse to receipt of the transaction initiation, the GUI including oneor more graphical control elements (GCEs) for selection of a credential;obtaining, via the GUI, an indication of a selected credential inresponse to a selection of a GCE of the one or more GCEs; providing theindication of the selected credential to a virtual POS terminal (vPOS)operating within the TEE to process the transaction.
 42. The method ofclaim 41, wherein the selected credential defines authenticationparameters required to validate an identity of a party to thetransaction.
 43. The method of claim 42, further comprising: receivingencrypted transaction data from the vPOS, the transaction data beingbased on the authentication parameters; and transmitting the encryptedtransaction data to the remote computing system.
 43. The method of claim42, further comprising: receiving a personal identification number (PIN)solicitation upon proper authentication of the user by the remotecomputing system; generating and rendering another GUI including one ormore other GCEs for input of a PIN; obtaining, via the other GUI, aninput PIN in response to a selection of some or all of the one or moreother GCEs; and providing the input PIN to the vPOS operating within theTEE to authenticate the user.
 44. The method of claim 41, wherein thetransaction initiation includes a transaction amount of the transactionor a currency value to be used to process the transaction.
 45. Themethod of claim 41, wherein the transaction initiation is included in ashort message service (SMS) message, a multimedia messaging service(MMS) message, an Over-the-Top (OTT) message, a push notification, or anemail message.